What does the warning message mean? What am I supposed to do? (There is a long list of warnings that looks similar to this.)
test>npm install #material/mwc-textarea
npm WARN #rollup/plugin-commonjs#21.0.1 requires a peer of
rollup#^2.38.3 but none is installed. You must install peer
dependencies yourself
EDIT: Some clarifications as suggested by #Konstantin Lyakh. I understand "peer dependencies" as described here. And the version info as described here.
But I do not understand how this fits together. I have the latest version of rollup installed (v2.67.2). As I understand it this should work with the requirement rollup#^2.38.3 but the WARNING suggest it does not. (And the mwc-textarea does not work as far as I can see.)
Related
I tried installing this module with npm, but recieved a bug which I cannot understand.
I have tried to install multiple versions of the package, including the dev-version and none has yielded any good results.
I am Wondering wether I have to downgrade my react install or if there might be any other solutions?
I cannot follow the error message I recieved, and I get confused about what is really the issue. I did think it might be the servers that were down, but when this keeps happening, I do not know what to do.
Thanks in advance!
I am working on an npm package that is used as a CLI to generate code. It makes sense that this project should generally be used as a devDependency.
But the generated code will require a third-party library at runtime. Is there a way to manage this dependency via package.json? I have seen other libraries include a note in the README that defines this dependency, but there is no guarantee that the end user will read this README, so I would like to be able to enforce this.
One thought I had was to use a preinstall script to validate that this third-party library was already installed, otherwise throw an error and don't allow the user to install. But that feels like more of a hack than a solution.
I anticipate someone saying "but won't it be obvious when none of the generated code works?" which is absolutely correct, but ideally this process should fail well before runtime.
I am not sure the specifics really matter here, but my package generates boilerplate TypeScript code for an API project, from an OpenAPI spec, and depends on Express.js at runtime.
This sounds like a peer dependency. You can specify a peer dependency in package.json with the peerDependencies key.
In npm 6, missing peer dependencies will result in a warning.
In npm 7, missing peer dependencies are installed.
There are a number of questions here on SO, which deal with the problem of conflicting/missing peer dependency, but they all seem to be directed at a very specific library (or got no answer at all).
I would like to know how to solve this problem in general. When a dependency requires a specific version of another lib and I have a newer version installed (example: React 17.0.1 as project dependency, react#^15.3.0 || ^16.0.0-alpha, required by react-virtualized-auto-sizer#1.0.4), how can I fix this situation?
So far I ignored the warning and the application seems to work fine. But I don't want to rely only on the current appearance.
Somewhere I read that such "local" versions are resolved (by NPM) by placing the 4th party dep in a sub node_modules folder of the lib, which requires it, but I haven't seen this happening.
We're using NodeJS for some projects and are faced with an issue that must have a simple solution (seeing as nobody else seems to have the problem).
In the packages.json there are a bunch of dependencies mentioned with a minimum version, each of which may have overlapping dependencies of their own. The default way a dependency is added is using the ^ operator which seems to mean 'compatible with' or 'same major version, but minor versions may differ'.
The way I understand npm to work is on npm install to take the highest minor version available that matches. Unfortunately 'compatible with' is not quite as enforced as you'd hope.
The situation this puts us in is that for instance on a developer machine version 1.1.0 is installed, but between development and publishing a new version 1.2.0, that has a bug, is introduced. On our build machine a fresh build is made which ends up using 1.2.0 and we've introduced a bug that wasn't there in development.
We tried changing the ^ operator to = for instance, but this gives us trouble when dependencies have subdependencies that aren't compatible with the requested version.
All in all I'm a bit confused, but this thing keeps biting us anytime something changes since the development machines don't do anything on npm install if the package is already there, but the build machine always gets fresh copies.
I know from NuGet that it always takes the lowest version that matches all combined requirements. Since this is always the same for a given set of dependencies, I much prefer this approach. Is there a way to make npm work like this too?
To answer my own question:
npm has introduced a new command npm ci which does something similar to npm install but enforces that the specific versions are used that were also used when a package was initially added by using the package-lock file.
See https://docs.npmjs.com/cli/ci for more information
how to solve this problem.
I run this commands make node-sdk on hyperledger/fabric folder (with sudo or without), still i am getting the same errors.
npm WARM hfc#0.6.2 license should be a valid SPDX license expression log file
this is harmless, the hfc module should still work despite the warning. By the way, if you are still developing with Hyperledger Fabric, there's a v1.0 release now. Checkout the details at hyperledger-fabric.readthedocs.io/en/latest/