Trying to install a dev dependency but one of its dependencies is lodash: 4.17.20. When Snyk does a scan of my dependencies, it marks this dependency as a high security vulnerability.
How can we have this dev dependency try to resolve a different version of lodash for a dev dependency and pass the Snyk test?
Was thinking that in the yarn.lock file, it somehow needs to resolve a higher version of lodash for this dev dependency, so I've referred to https://classic.yarnpkg.com/en/docs/selective-version-resolutions/
Doing something in my package.json like
"resolutions": {
"**/lodash": "^4.17.20"
}
Or
"resolutions": {
"<that dev dependency>/lodash": "^4.17.20"
}
Seems like it hasn't quite worked, and the Yarn.lock hasn't updated the lodash dependency for that dev dependency. Wanted to see if this was possible without updating the yarn.lock manually as I could see it being re-overwritten in the future. This is done in a Lerna monorepo.
Update from the Snyk team, they do not have monorepo support with Lerna as of 04/05/21
Related
Should I install #vue/composition-api in package.json dependencies rather than in devDependencies?
I see on npm registry that it is in dependencies
Following the logic of vue-property-decorator or vue-class-component, this are installed as dependencies.
I would say this is actual dependency for your project once is build, so it is not a dev dependency.
My project depends on analytics-node which has a dependency on axios: "^0.16.2".
We have been flagged with npm audit that axios has a vulnerability in it but its fixed in 0.18.1.
However, analytics-node has no release candidate (only beta) which depends on 0.18.1 or higher.
We have tried:
npm audit fix,
npm update axios --depth 2,
npm install axios#0.18.1
The part I am most confused about is why doesnt npm allow us to override analytics-node version of axios given that the version should be compatible.
npm-force-resolutions specifically fixes transitive dependency version resolutions for this exact reason.
It would be nicer if there was a supported way to do this with package-lock.json though.
NPM 8 introduced "overrides" which allows you to override specific transitive dependencies of your direct dependency. For your usecase, you would declare something like below in your package.json.
{
"overrides": {
"analytics-node": {
"axios": "0.18.1"
}
}
}
More details # https://docs.npmjs.com/cli/v8/configuring-npm/package-json#overrides
To bump (i.e. update) a transitive dependency in a package-lock.json file, you can use the npm command line interface (CLI). To update a transitive dependency, you will first need to identify the package that you want to update. Then, you can use the following steps:
Navigate to your project directory in the terminal and run the npm ls command to list all of the dependencies in your project, including transitive dependencies. This will show you the full dependency tree, with each package and its dependencies listed in a hierarchical structure.
Find the package that you want to update in the dependency tree, and note the version number of the transitive dependency that you want to update.
Run the npm install command, followed by the name and version of the package that you want to update, in the following format: npm install <package-name>#<version>. This will update the specified package to the specified version.
Run the npm ls command again to verify that the transitive dependency has been updated. You should see the new version number for the package listed in the dependency tree.
If you want to save the updated dependency in your package-lock.json file, run the npm shrinkwrap or npm update command, depending on which version of npm you are using. This will update the package-lock.json file to reflect the updated transitive dependency.
Note: Bumping a transitive dependency in package-lock.json can potentially cause conflicts or other issues if the updated dependency is not compatible with your project's dependencies. It is recommended to carefully review the dependencies and their versions before updating any packages.
I checked out a repo which uses yarn instead of npm as build tool.
in the package.json, it defines workspaces to deal with multiple sub-projects:
{
"workspaces": [
"packages/*"
],
"dependencies": [],
"devDependencies": [
// long list
]
}
As a result, the root package.json does not contain any runtime dependency. Just the packages/*/package.json contain those.
To compile (and start in dev mode) I do:
yarn install
yarn start
I have found no documentation, that workspaces is also recognized and correctly used by npm.
Is there a way to make it work with npm, too?
Now that npm v7.0.0 is out, npm supports workspaces. You can manage multiple packages from within a singular top-level, root package. See more at https://github.blog/2020-10-13-presenting-v7-0-0-of-the-npm-cli/
Your workflows will not get npm v7.0.0 by default unless you install it using npm install -g npm#7.
Managing dependencies in a monorepo is not supported with npm. The Lerna package is used to manage JavaScript projects with cross dependencies. I believe Lerna uses Yarn under the hood, but with Yarn as your project's package manager, this feature is supported out of the box.
Here is a repo that might be helpful to see how Yarn and Lerna work together: https://github.com/Quramy/lerna-yarn-workspaces-example
npm has plans to implement workspaces somewhere along the v7, hopefully. They've written about it in their blog and there's an accepted proposal.
As of 2020-08-11 Workspaces are available in the v7 beta.
RFC 26 First phase of workspaces support is added. This changes
npm’s behavior when a root project’s package.json file contains a
workspaces field.
https://blog.npmjs.org/post/626173315965468672/npm-v7-series-beta-release-and-semver-major
You can view and download the beta here:
https://github.com/npm/cli/tags
NPM version 7 support workspace management. Now we can manage our workspace dependencies using npm workspace.
More on the workspace support can be found here official site here.
https://docs.npmjs.com/cli/v7/using-npm/workspaces
If you are looking for a simple example follow this link
https://github.com/pravanjan/npm-workspace-example/tree/master
Tested using node v16.6.1
npm 7.20.3
Does it make sense to put any modules into package.json dependencies when I use webpack?
When I want to develope a package, I use git clone <url> then npm install, then npm installs all dependencies and devDependencies from package.json file and it makes sense.
When I'm end-user and I just want to install some package into my node_modules to use it in my project, I run npm install package-name, then npm installs package-name with only its dependencies, and it makes sense too.
But does it make sense to put any modules into dependencies when I use webpack? The webpack will bundle all dependencies into eg. bundle.js, so, for me, there is no need to install dependencies then (while they're included into bundle.js file).
Let's assume that I put all neccessary modules into devDependencies (keep the dependencies object empty) for my project: my-project, bundle it with webpack and publish:
the developer-user will use git clone <url to my_project>, then run npm install, then npm will install devDependencies from package.json (and ommit empty dependencies object), then it is ready to develope.
the end-user will use npm install my-project, then npm will install my-project, do not install devDependencies (because this is for production) and do not install dependencies (because dependencies object in package.json remain empty). Putting anything into dependencies would double the dependencies: both the dependencies would be installed, and the same dependencies would be accessible in the bundle.js file.
Am I right?
You are correct that there may be no dependencies once it's been transpiled with webpack. However, some packages are multi-purpose and may be used in multiple ways, so in some circumstances dependencies may still be required.
If you look at the package.json specification, there are two possible entry points, 'main' and 'browser'. There is also the proposed 'module' entry point. It is currently under discussion about how to handle these in webpack and users seem to want webpack to prioritize them as module > browser > main, however browser is currently used by webpack first.
The idea behind prioritizing them in the order module > browser > main is presumably that browsers could use the pre-transpiled stuff directly in "browser", whereas another project calling require() or include() on your package would use non-transpiled code from the "module" entry. The "module" entry code could contain modern JavaScript with new features and the project/package requiring it could then transpile it to their own specifications, using "browserslist" for example.
I found this question because I was wondering the same thing...
I see --save-dev mentioned in Gulp tutorials and from what I see, it adds npm functionality to a project's dependency.
But what does that mean exactly? Is that significant when the project gets moved from one machine to another?
Thank you for any clarification of --save-dev importance with Gulp.
In a npm package there 2 types of dependencies: the production ones and the development ones.
{
"dependencies": {
// .. a list of production dependencies
// i.e. angular or express
},
"devDependencies": {
// .. a list of dependencies strictly needed only in development mode
// i.e. gulp or grunt
}
}
You need the former to make the application run in production. The latter are used when in development mode, so everything around the build system, minification, etc...
Gulp, as a building system, is more a devDependency by nature, than a production dependency. This is why you often find in Gulp/Gulp plugins tutorials things are:
$ npm install --save-dev gulp
That --save-dev flag will put the installed dependency you're asking in the devDependencies bucket while using --save sets the dependency in the dependencies (production) one.