How do I find, within my project, all the dependencies that have a peer dependency on a specific library?
The use case is that I have to update the version of the library X, and I want to know which library peer-depends on X so that I know in advance what other libraries I have to check to be sure to not break the compatibility.
I'm thinking about something like yarn why <x>, but for peer dependencies.
Related
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.
I am trying to write my first set of npm libraries for a large, distributed application and am running into problems around how to manage dependencies. Npm has the concept of "dependencies" and "peerDependencies".
From what I read, peerDependencies are needed when you want to write a "plugin" where the consuming application is already expected to have the dependency installed on their end. For example, this might be building a plugin for webpack.
Then there are regular dependencies needed at runtime by a library. In my scenario, I am trying to write a library to abstract Authentication and Authorization away from the consuming application. This new library (lets call it #myapp/auth) has a dependency on the #auth0/angular-jwt library as it uses it to deal with JWTs. I want this library to be completely abstracted away from the consuming application and therefore not force that consuming application to install it manually.
With that said, it sounds like I need to add #auth0/angular-jwt to dependencies in my library and then add it to the whitelistedNonPeerDependencies which allows it to build.
This confuses me because the ng-packagr docs say that we should always use peerDependencies when possible. If this is the case, then why when you install a larger library like express, you simply run npm install express --save and you get ALL of the dependencies of express without manually installing each one.
What is the proper way to include package dependencies in a custom library that you do not want the consuming application to install themselves?
Lets say I am working on a library that will be consumed by other developers. MyPackage has a dependency on moment. The developer that consumes my package also has a dependency on moment. So moment will exist as a "dependency" in both library package.json and application package.json (and thus get packaged twice). Is there a way to package it just once? If the consumer has it, use theirs, else use mine?
It's already happening by default on fresh installs if dependency ranges match.
npm v>=3 does gang the dependencies, depending on the installation order and depth, see here.
Also, if you kept working on the same folder for a while, there might be some cruft, which could be wiped using npm dedupe, see here.
In theory, moment should not be duplicated if both your library and developer's library are consuming the same version ranges of it. At least if npm dedupe is called or node_modules are wiped and npm i-nstalled.
So here is the problem
I installed systemjs from the online npm repo to a new empty project which was fine. I then republished this to an internal nexus repository which appeared to work.
However when I tried to install the systemjs repository from our nexus directory, the 'when.js' package was installed within the same node_module level as the systemjs package i.e. myproject->node_modules->when ? Not within myproject->node_modules->systemjs->node_modules->when ?
Can you tell me what I need to do to ensure that the systemjs dependancies are installed within myproject->node_modules->systemjs->node_modules->XXX and NOT myproject->node_modules->XXX ?
Since npm v3 the dependency tree is kept as flat as possible to avoid duplication and overly deep directory structures. That results in placing the dependencies at the same level as the module that required them, unless there already exists another version of the dependency in which case it is installed nested. See the npm documentation for details.
In most cases you shouldn't have to worry about the structure of your node_modules directory. If you absolutely need to have all the dependencies nested, the only way currently seems to be downgrading npm to v2.