npm issues with UNMET PEER DEPENDENCY, related to react-native - npm

I think I'm confused as to how npm manages dependencies. I see this:
npm list react-native
project#0.0.1 /Users/me/workspace/project
└── UNMET PEER DEPENDENCY react-native#0.15.0
npm ERR! peer dep missing: react-native#^0.13.2, required by react-native-dialogs#0.0.5
npm ERR! code 1
So I try... but I get:
npm install react-native#0.15.0
....
project#0.0.1 /Users/me/workspace/project
└─┬ UNMET PEER DEPENDENCY react-native#0.15.0
└── react-tools#0.14.0-beta1 (git+https://github.com/facebook/react.git#b4e74e38e43ac53af8acd62c78c9213be0194245)
npm WARN EPEERINVALID react-native-dialogs#0.0.5 requires a peer of react-native#^0.13.2 but none was installed.
npm ERR! code 1
My package.json:
{
"name": "project",
"version": "0.0.1",
"private": true,
"scripts": {
"start": "react-native start"
},
"dependencies": {
"apsl-react-native-button": "^2.1.0",
"base-64": "^0.1.0",
"es6-react-mixins": "^0.2.1",
"fifo": "^2.3.0",
"money-math": "^2.2.0",
"react-native": "^0.15.0",
"react-native-dropdown-android": "0.0.4",
"react-native-lightbox": "^0.5.0",
"react-native-mail": "^0.2.4",
"react-native-router-flux": "^0.3.4",
"react-native-simpledialog-android": "^1.0.2",
"react-native-swiper": "^1.3.0",
"superagent": "^1.4.0",
"tcomb-form-native": "^0.3.0",
"utf8": "^2.1.1",
"react-native-facebook-login": "^1.0.0"
}
}

I know it's an old question, but a response can still be useful for others seeing this in the future.
Explanation of the issue
In your package.json, you are installing the dependency react-native-dialogs#0.0.5 which is as well expecting as a peerDependency the module: react-native#^0.13.2. Since that project is public, it can be verified in their package.json file:
"peerDependencies": {
"react-native": "^0.13.2"
}
The first part of this statement, is the module name, and the second part, the supported version range.
This means that the root module should provide such dependency and in such version range, in order for the installation to succeed with no errors. In this case, it's stating react-native dependency, and in the ^0.13.2 version range.
Now, in your package.json, you are listing the dependency:
"react-native": "^0.15.0",
So why is it not working? The ^ (caret) in version range should include all patch and minor versions in the same major, right? (ie. in "^X.Y.Z" range, all X.*.* should work, right?). Well, turns out this isn't true for pre-1.x ranges. For 0.x ranges, the ^ caret only covers patch versions inside the range (source: NPM docs).
Therefore, per this rule, "^0.15.0" is not in the range of "^0.13.2", so this is why you get the UNMET PEER DEPENDENCY error.
Possible solutions
You have a few options here.
Provide the expected peer dependency
The most straightforward one, is providing the expected peer dependency in a version that is in the expected version range.
So you could use the same version range, in this case: "^0.13.2". Or specify an exact version as well, for example: "0.13.2".
Tip: you can check all versions that match the requested range for a given package, using this utility https://semver.npmjs.com/.
For this case, the only version that exists and matches the range is "0.13.2", but there could've been more (ie. "0.13.3" could've been fine as well, if it existed. But "0.14.0" or "0.12.0" won't work, as explained above)
Update your module dependency
In many cases the original module gets upgraded, and changes may include supporting different or more broad peerDependencies packages/versions.
As of today, I can see in the package.json on the project master branch, that the current module version is 1.1.1 and the peerDependencies have been removed, so upgrading your "react-native-dialogs" dependency version ^0.0.5 -> ^1.1.1 will do the job for this scenario.
But, what if this didn't happen, or if you didn't want to upgrade to the latest version?Let's explore more options.
Change the module itself that you want to depend on
In case that providing the dependency version requested as a peerDependency by a module you use conflicts with your requirements, and upgrading this dependency to a newer version that removes this constraint doesn't work for you.
The allowed range "^0.13.2" might be quite limited, ie. it won't support version 0.14.0 and onwards. The reasoning behind this, could be based on compatibilty issues, or maybe just a lack of awareness in allowing/supporting for more versions. There could happen to exist other versions that can work fine, but the original developer did not take the extra steps to include them.
So you just want to continue using this exact module as is, but allow a newer react-native version.
Imagining the original scenario, that 0.0.5 was the current latest version in the master branch, it could make sense raising this as an issue to the original module repo, and/or submit them a PR proposing a broader supported range. For example:
"peerDependencies": {
"react-native": "< 1.0.0"
}
The range "< 1.0.0" would now allow the "^0.15.2" version range.
What if you didn't want to allow all the 0.x versions? Then you could use a more narrow range, such as: "> 0.4.0 < 1.0.0". Take a look at NPM semver docs for syntax, a lot more possibilities are allowed too.
Don't use that module at all / Build your own
It can happen that the original module can be abandoned, have bugs, or just not work for your all of your requirements. In this case, you can look for a some alternative available in the community, or even build one yourself.
Since this module is public you can even fork the project and upload a new package version yourself with the changes you want (you'll have to use a different package name of course).

Try the "--save" argument for "npm install" command, like:
npm install react-native#0.15.0 --save

Related

Why are certain conflicting peer dependencies resolved when you remove the package-lock.json and node modules

Context
I joined a new project where I was asked to upgrade React from version 17 to 18. After upgrading react and react-dom and some other dependencies I got some warnings, which had to do with dependencies.
npm install react#latest react-dom#latest
Some of them I was able to resolve easily, by updating some packages. This was until I tried resolving the following warning:
npm WARN Conflicting peer dependency: react#17.0.2
npm WARN node_modules/react
npm WARN peer react#"^16.3.0 || ^17.0.0" from react-side-effect#2.1.1
npm WARN node_modules/react-helmet/node_modules/react-side-effect
npm WARN react-side-effect#"^2.1.0" from react-helmet#6.1.0
npm WARN node_modules/react-helmet
Already I am a bit surprised by the react#17.0.2. Apparently there is another version of React still in dependencies, that is required by another package.
Package that requires React 17.0.2
"<CUSTOM PACKAGE MADE BY SOMEONE ELSE>": {
"version": "0.3.0",
"resolved": <LINK>,
"integrity": "sha1-Ah72HLxApcdcSPGRIE/L7wjy8Ec=",
"dependencies": {
<CUSTOM PACKAGE MADE THE SAME PERSON 2>: "^0.1.6",
"react": "^17.0.2",
"react-dom": "^17.0.2",
"react-scripts": "5.0.0"
}
},
The actual dependency
"react": {
"version": "17.0.2",
"resolved": "https://registry.npmjs.org/react/-/react-17.0.2.tgz",
"integrity": "sha512-gnhPt75i/dq/z3/6q/0asP78D0u592D5L1pd7M8P+dck6Fu/jJeL6iVVK23fptSUZj8Vjf++7wXA8UNclGQcbA==",
"requires": {
"loose-envify": "^1.1.0",
"object-assign": "^4.1.1"
}
Ancillary Question
Would having 2 versions of React in your package-lock.json not cause problems? I can't imagine these two version be used simultaneously. My guess would be that in this case this should be a peer dependency, am I correct to assume that?
Attempts
At first I thought that I could not update React yet, until react-helmet would be patched. I let my colleagues know, and they all said that another project also used react-helmet and they were able to update React. What?! Great impression on new colleagues 😄.
Indeed opening the other project and installing the new React version there did not cause the same warning.
Question
As an experiment I decided to remove the package-lock.json entirely. This resulted in the same errors. Removing the package-lock.json and the node_modules resolved it however! Why is this the case? The package that requires React 17.0.2 is still there as is the dependency for React version 17.0.2. Yet somehow, it is no longer a problem.
Any help to understand why this would resolve the situation would be greatly appreciated.
Note
react-helmet seems to be unmaintained, so will need to be removed eventually. This is not what my question is about.
Apparently removing the node_modules and package-lock.json did not help at all. Removing both does not trigger the warning the first install. Once you run npm install again, the same warning will show.
So it seems the warnings do not show up at the first 'clean' install. This also seems to be true at the other project, however there is something more going on there.
In this case it will probably mean that we will need to replace react-helmet with react-helmet-async and update the version of the custom package.

npm:confirm the behavior of npm install for this case? Why there is no nested dependency?

In application, I come across some issue when installing npm packages.
the package.json goes as following:
"dependencies": {
"#angular/cdk": "7.2.1",
"privateLib": "19.0.0",
}
I only show the critical part and hide other things. The privateLib is one private package you can ignore the name.
And after npm install, it reports the following warn message:
npm WARN privateLib#19.0.0 requires a peer of #angular/cdk#7.3.7 but none is installed. You must install peer dependencies yourself.
And I checked the installed #angular/cdk is version 7.2.1.
The confusing points is that, inside the privateLib, its own package.json config goes like this:
"dependencies": {
"#angular/cdk": "7.3.7",
}
I checked there is no #angular/cdk package inside privateLib. So why it doesn't install its own dependency of version 7.3.7 in a nested way. This behavior is not same as the npm3 document: https://npm.github.io/how-npm-works-docs/npm3/how-npm3-works.html
I'm using npm v6.
Indeed, per https://blog.npmjs.org/post/110924823920/npm-weekly-5:
We will also be changing the behavior of peerDependencies in npm#3. We won’t be automatically downloading the peer dependency anymore. Instead, we’ll warn you if the peer dependency isn’t already installed. This requires you to resolve peerDependency conflicts yourself, manually, but in the long run this should make it less likely that you’ll end up in a tricky spot with your packages’ dependencies.
Try https://github.com/spatie/npm-install-peers to facilitate.

NPM package.json convert * asterisk to version

I have a package.json from my template with several dependencies.
If I want to create a new project, I use my template.
But how to convert all * (asterisk sign / latest version) to a fixed version which is downloaded from npm. npm install --save does not work.
Before npm install (template package.json)
"devDependencies": {
"one": "*",
"two": "*",
"three": "*"
}
should convert to following by npm i --save.
"devDependencies": {
"one": "1.0.0",
"two": "2.0.0",
"three": "3.0.0"
}
How to overwrite the version string?
As per the documentation
(*) --> Matches any version
("") --> (just an empty string) Same as *
The workaround of this issue is shrinkwrap(Read documentation for further information). You can use this command npm shrinkwrap.That creats a npm-shrinkwrap.json file. When you run the command,You get the following comments on console (npm notice package-lock.json has been renamed to npm-shrinkwrap.json. npm-shrinkwrap.json will be used for future installations.). And that will gave the updated package version whatever you have in package.json.
Use npm list --depth=0 to see what versions were installed by installing 'latest' from your template. You should get something like this:
├── #angular-devkit/architect#0.1501.1
├── #angular-devkit/build-angular#15.1.1
├── #angular-eslint/builder#15.2.0
Copy, modify and paste output into your package.json. Then you should probably remove node_modules and check if running npm ci works properly.
Notes:
This is how you should specify wanted versions in package.json:
"react": "^16.0.0" // carat: allow 16.1.0
"react": "~16.0.0" // tilde: allow 16.0.1
"react": "16.0.0" // exact: only 16.0.0
If your template is fairly complicated, it is highly unlikly that such workflow would be convenient. I would advise having specific versions in the template carefully combined, so that they work. Then, once every couple of months, you should (again, carefully) updgrade libraries in your template. Otherwise, sooner or later you are going to install two latest version of some conflicting pakages.

Should I change all npm packages's distag in package.json to "latest"?

I'm building a boilerplate for my every frontend projects and if I wanted when I run npm install so all my dependencies will be the latest version, Would I change all the packages' distag to "latest" for that purpose?
"#babel/plugin-syntax-dynamic-import": "latest",
"#babel/plugin-transform-runtime": "^7.3.4",
"#babel/preset-env": "^7.3.4",
"babel-eslint": "^10.0.1"
to
"#babel/plugin-syntax-dynamic-import": "latest",
"#babel/plugin-transform-runtime": "latest",
"#babel/preset-env": "latest",
"babel-eslint": "latest"
The package-lock.json
npm v5.2+ comes with a package-lock.json file that is generated when you install packages. This file should be versioned because it contains the information of every package installed.
The idea then becomes that instead of using package.json to resolve and install modules, npm will use the package-lock.json. Because the package-lock specifies a version, location and integrity hash for every module and each of its dependencies, the install it creates will be the same, every single time. It won’t matter what device you are on, or when in the future you install, it should give you the same result every time, which is very useful.
So, if package-lock.json locks down the version of installed packages, what is the problem using "latest"?
The problem lies in that your package.json is not meaningful.
Your package.json does not tell you what version is actually installed, not even a clue.
What if someone overrides the package-lock.json or deletes it.
It is not the end of the world, but having a package.json should give us a clue about the packages we have installed.
Of course you can see a list of your installed packages with versions: npm list --depth=0 and also if you want to update packages, you can see the list of outdated ones: npm outdated
Check out this article: Everything you wanted to know about package-lock.json but were too afraid to ask.
I think it is ok when you use lastest tag as there is no conflict in version of packages.
In the user's guide of distag, they show that:
By default, the latest tag is used by npm to identify the current version of a package, and npm install <pkg> (without any #<version> or #<tag> specifier) installs the latest tag. Typically, projects only use the latest tag for stable release versions, and use other tags for unstable versions such as prereleases.
So if you are gonna to release a stable version, use latest tag will definitely true.

What exactly does "next" mean in package.json dependencies?

What exactly does next mean in package.json dependencies?
"dependencies": {
"react": "^15.4.2",
"react-dom": "^15.4.2",
"react-router-dom": "next"
}
The next tag is used by some projects to identify the upcoming version.By default, other than latest, no tag has any special significance to npm itself.
NPM Documentation
Specifically, and according to the documentation I found this helpful:
By default, the latest tag is used by npm to identify the current
version of a package, and npm install (without any # or
# specifier) installs the latest tag. Typically, projects only
use the "latest" tag for stable release versions, and use other tags for
unstable versions such as prereleases.
The next tag is used by some projects to identify the upcoming
version.
By default, other than latest, no tag has any special significance to
npm itself.
So, for instance, I had some issues related to npm itself generating npm ERR! Error: EACCES: permission denied errors on package installations, that I first corrected by reverting to an earlier version of npm (from 5.4.0):
npm install -g npm#5.3.0
But npm is also one of those packages that does use the "next" tag in their distribution, so to take advantage of that in the newest but not officially "stable version", you could also run:
npm install -g npm#next
Which installed 5.5.1
Running: npm show npm versions --jsonshows the following version history to give an idea what exactly was installed:
[ ...
"5.3.0",
"5.4.0",
"5.4.1",
"5.4.2",
"5.5.0",
"5.5.1"
]
This answer is an attempt to state the purpose of #next more simply. The language in the docs and in other answers appears overly complex.
Using next as the version number will allow a pre-release version if the project has one available. It will otherwise allow the latest stable version.