I am trying to follow the instructions in this repository to patch Jest.
Patch Jest.
It is suggested to use patch-package but I figured out that I can use yarn patch when using Yarn 2.
I managed to patch jest-runtime but seems Jest doesn’t seem to require jest-runtime in its package so I don’t know where it comes from to use it as a reference to declare the patched file.
Jest package.json
I understand if Jest was the one that needs to be patched I could declare it like this:
package.json
"devDependencies": {
"jest": "patch:jest#26.6.3#./patches/jest.patch"
}
I tried to use the same logic to include the following code to include jest-runtime but it didn't work.
"devDependencies": {
"jest": "^26.6.3",
"jest-runtime": "patch:jest-runtime#26.6.3#./patches/jest-runtime.patch"
}
How can I declare this patched jest-runtime so Jest can use it?
The Resolutions field in the manifest is the correct approach to declare the patched modules that we didn't add to devDependencies such as submodules.
The resolutions field allows you to instruct Yarn to use a specific resolution instead of anything the resolver would normally pick. This is useful to enforce all your packages to use a single version of a dependency, or backport a fix.
The fix for that issue:
{
...
"dependencies": {
"jest": "^26.6.3",
},
"resolutions": {
"jest-runtime": "patch:jest-runtime#26.6.3#./patches/jest-runtime.patch"
},
}
Related
I used the variables in the title of this topics, but I also have the live example.
The alpha version 1.5.0-alpha.0 of the package #yamato-daiwa/es-extensions-localization-japanese depends on version 1.5.1 of #yamato-daiwa/es-extensions:
{
"name": "#yamato-daiwa/es-extensions-localization-japanese",
"version": "1.5.0-alpha.0",
"dependencies": {
"#yamato-daiwa/es-extensions": "1.5.1"
},
"peerDependencies": {
"#yamato-daiwa/es-extensions": ">=1.5.0 <1.6.0"
},
// ...
}
If to install the correct versions of both packages, both distributables will be put directly below node_modules/#yamato-daiwa:
{
"private": true,
"dependencies": {
"#yamato-daiwa/es-extensions": "1.5.1",
"#yamato-daiwa/es-extensions-localization-japanese": "1.5.0-alpha.0"
}
}
Now let's assume that I made a mistake and installed the version 1.5.0 of #yamato-daiwa/es-extensions. In this case, the additional instance of #yamato-daiwa/es-extensions will be put below node_modules/#yamato-daiwa/es-extensions-localization-japanese/node_modules.
The localization will be applied anymore, but there also will be any error, so if it was not the experiment, I could not undestrand the cause.
How to make use install the appropriate version of #yamato-daiwa/es-extensions? Is more strict peerDependencies like "#yamato-daiwa/es-extensions": "1.5.1" will be enough?
As you noted - you have 2 installations #yamato-daiwa/es-extensions - in main app's node_modules and in #yamato-daiwa/es-extensions-localization-japanese node_modules. Your application uses the package from its node_modules folder, but the localization uses another instance from its node_modules. That's why localization is not working.
To prevent this, you should enable strict-peer-deps property in the project's .npmrc file. npm will treat non-compatible peer dependencies as a failure.
I have a huge project, which I was will simplify for the issue, with 2 workspaces.
The main packages looks like
workspaces: [ 'workspace-A', 'workspace-B' ]
My workspace-A has a dependency to external package (here, jest), in a needed version
name: "workspace-A",
dependencies: {
"jest": "<27.0.0"
}
My workspace-B has a dependency to the same package, but doesn't care about its version.
name: "workspace-B"
dependencies: {
"jest": "*"
}
After a yarn install (with yarn v3), I was expecting yarn to automatically install jest with a 26.x.x version in my main node_modules.
Instead, the node_modules of the main project contains jest 26.x.x, and the node_modules of the workspace-B contains jest 27.x.x. It's OK for my, even if I find this weird, but the thing is the workspace-A now uses jest 27.x.x!
I succeeded make it work by adding a resolution field in the main package file, but it's not ideal, as this package doesn't need jest.
"resolutions": {
"jest": "^26.6.3",
}
My 2 questions are
Why is yarn installing 2 versions of jest, is there a way to prevent this?
Is there a configuration somewhere I should put to specify to the workspace-A to not use something from workspace-B?
Thanks for reading
I would like to update a 'handlebars' node module that is a dependency of Vue-Cli (see screenshot).
What's the correct way to do this?
Thank you
Add a resolutions field to your package.json file and define your version overrides.
It will look like this
{
...
"dependencies": {
...
},
"devDependencies": {
...
},
"resolutions": {
"EXAMPLE_PACKAGE": "EXAMPLE_PACKAGE_NEEDED_VERSION"
}
}
It shouldn't update the package in the dependency. But your application will use the needed version. It can be useful for example if some dependencies in your dependency have important security updates, and your dependency has not updated the version yet.
Trying to figure out how to declare RxJS as a peer dependency for an Angular 6 project I'm working on. For example I looked at angular/flex-layout and it declares it's RxJS dependency like this:
"requiredAngularVersion": ">=6.0.0 <7.0.0",
"dependencies": {
"rxjs": "^6.0.0"
}
Just curious why it's declared like that and not like this:
"requiredAngularVersion": ">=6.0.0 <7.0.0",
"peerDependencies": {
"rxjs": "^6.0.0"
}
Side Note
Noticed that some projects are matching their major semver version to Angular's Major version. So for example I'll be using major version 6 for the #fireflysemantics/slice in order to match it up with Angular 6.
Just curious why it's declared like that and not like this:
It should be a peerDependency. They probably don't want to force people to use 6.0.x which is what dependencies does.
So I have a React project, in which I'm actually deploying with react-lite as the footprint is much smaller. I'd like to use react-nouislider, but in it's package.json, I've found this:
"peerDependencies": {
"react": "^0.14.0"
}
What this means is that whenever I require react-nouislider, it pulls in React instead of react-lite. How do I shim dependencies of an npm package from my top-level package.json?
This is how I'm shimming react-lite in:
"browser": {
"react": "react-lite"
}
And I tried this, but it didn't work:
"browserify-shim":{
"react-nouislider": {
"depends": "react-lite"
}
}
How is it possible to shim a dependency of a package itself?
Browserify Shim's tagline is:
Makes CommonJS incompatible files browserifyable.
Your issue here is that react-lite is already CommonJS compatible. For any CommonJS compatible file, Browserify will automatically add its dependencies and peerDependencies as appropriate, before Browserify Shim gets involved.
I suggest you change the peerDependencies entry in the react-nouislider package to the appropriate version of react-lite and remove your Browserify Shim config above as it's no longer needed. When you do this, be sure to run any tests in the react-nouislider package to make sure it still works with react-lite instead of React. A good way of doing this is forking react-nouislider to your own repo, making the change there, and pulling from that repo in your package.json.