I issue npm install protractor.
Under /path/to/node_modules/protractor/node_modules, i was expecting all the internal dependencies of protractor npm. But i am seeing only one module, q.
However in /path/to/node_modules/protractor/package.json, i can see all dependencies of protractor listed as,
"dependencies": {
"adm-zip": "0.4.4",
"glob": "~3.2",
"jasmine": "2.3.2",
"jasminewd2": "0.0.6",
"lodash": "~2.4.1",
...................
}
Protractor module is versioned "3.0.0" and npm is versioned 3.3.12, node.js is versioned v5.1.0.
What has changed in these new versions? Since, all npm modules used to maintain their own dependency copies.
npm 3 flattens the dependency tree, so you should see protractor's dependencies in /path/to/node_modules.
If you don't see them there, my first guess is that you might have an npm-shrinkwrap.json file that is preventing modules from being installed, so you could check for that.
Related
I am getting 6 vulnerabilities after running npm audit report:
I tried a solution and overridden the vulnerable versions of a particular package with their latest versions in package.json file like this:
"overrides": {
"nth-check": "2.1.1",
"#svgr/webpack": "6.5.1",
"#svgr/plugin-svgo": "6.5.1",
"svgo": "3.0.1",
"css-select": "5.1.0"
}
Then I updated the npm packages with npm update. But it did not change the result.
Tried another solution by making a resolution object in package.json and specified specific versions of a particular package, and ran it using npx i npm-force-resolutions but it gives this error:
npm ERR! could not determine executable to run.
But I am still unable to fix the npm vulnerabilities. Please help!
You should delete both node_modules and package-lock.json before launching npm install again; this will require more time to install all dependencies, but this will override all the version that are currently installed (it will bring also minor updates in dependencies).
Also, for this vulnerability, you only need to override nth-check. You can see the changes by executing npm list nth-check with and without the override (remember to delete both node_modules and package-lock.json).
In my package.json I have
"dependencies": {
"components": "link:../components",
"react": "^16.9.0",
"react-dom": "^16.9.0"
}
This works fine during development, however when trying to publish the packages to npm the "link:../components" is published into the package.
Is there a way to take the "link:../components" and replace it with the version of the package.json in the file it's being linked with?
basically
"dependencies": {
"components": "link:../components",
"react": "^16.9.0",
"react-dom": "^16.9.0"
}
would convert to
"dependencies": {
"components": "1.2.3",
"react": "^16.9.0",
"react-dom": "^16.9.0"
}
before being published to npm. The linked dependency would remain locally, though.
npm link is a development utility to test your npm packages before you publish them.
https://docs.npmjs.com/cli/link
Using your example names, say you are developing a npm package components. While you are developing it, you want to test it in your main project (The consumer of your package).
The way to go about this is, to go in your components package dir, and run npm link, this will create a global link in your system that will make it available to other projects.
So now you can go in your main project dir, and run npm link components (components is the name of your package, not to be confused with dir name)
This is fine during development, but of course won't work when you publish your packages.
Is there a way to take the "link:../components" and replace it with the version of >the package.json in the file it's being linked with?
First publish components package to npm (A good
article
that explains it)
In your main project dir, run npm unlink
components.
This will remove the global link to components in your
project dir.
In your main project dir, run npm install components.
This will fetch components from npm.
In a node project I found 2 kind of dependencies:
"dependencies": {
"axios": "0.9.1",
"express": "4.13.4",
"lodash": "4.6.1",
"react": "^0.14.7",
"react-dom": "^0.14.7",
"react-redux": "^4.4.0",
"react-router": "^2.0.0",
"redux": "^3.3.1"
},
"devDependencies": {
"babel-core": "^6.5.2"
}
I know the author install it via npm install babel-core --save -dev
but what is that for? when you push your code, the devDependencies module is still there.
I wrote an article about this however it was taken down.
Snippets from the article:
mod-a
dev-dependents:
- mod-b
dependents:
- mod-c
mod-d
dev-dependents:
- mod-e
dependents:
- mod-a
----
npm install mod-d
installed modules:
- mod-d
- mod-a
- mod-c
----
checkout the mod-d code repository
npm install
installed modules:
- mod-a
- mod-c
- mod-e
Publishing to npm
If you are publishing to npm, then it is important that you use the correct flag for the correct modules. If it is something that your npm module needs to function, then use the "--save" flag to save the module as a dependency. If it is something that your module doesn't need to function but it is needed for testing, then use the "--save-dev" flag.
# For dependent modules
npm install dependent-module --save
# For dev-dependent modules
npm install development-module --save-dev
Not for npm
If you aren't publishing to npm, it technically doesn't matter which flag you use. However, I find it a good practice to use the "--save" flag for modules that introduce non-standard code into the source files. Then use the "--sav-dev" flag for modules that are required for your compiler to function.
# For modules that introduce non-standard source code
npm install source-module --save
# For modules that your compiler needs to function
npm install compiler-module --save-dev
Dependencies vs dev dependencies
Dev dependencies are modules which are only required during development whereas dependencies are required at runtime.
If you are deploying your application, dependencies has to be installed, or else your app simply will not work. Libraries that you call from your code that enables the program to run can be considered as adependencies.
Eg- React , React - dom
Dev dependency modules need not be installed in the production server since you are not gonna develop in that machine .compilers that covert your code to javascript , test frameworks and document generators can be considered as dev-dependencies since they are only required during development .
Eg- ESLint , Babel , webpack
Main difference between the two is:
-in devdependencies, developer customize or modify the node package according to the requirement. For example while making grunt task we change the task as per requirement in Gruntfile, same as case with babel you are using.
-in dependencies, developer directly use the node package without the change ex-express.
Hopefully it clears your doubt.
I'm having an issue with NPM installing two copies of React in my project. Here are the relevant parts of the dependencies:
My package.json:
"dependencies": {
"react": "0.12.2",
"tcomb-form": "0.4.5"
}
tcomb-form's package.json:
"peerDependencies": {
"react": ">=0.12.0"
}
I would not expect tcomb-form to get it's own copy of React, since I already have a dependency that satisfies its peerDependencies.
However, in npm 2.7.4, it does install a separate version in tcomb-form/node_modules/react, and this version is incompatible with my version (I use 0.12, and it is installing 0.13)
In npm 1.4.28, this behavior was different, and tcomb-form/node_modules/react would not exist, and it would just use my version.
Is there anyway to make it so that we all use the same version of React in the latest npm?
npm dedupe should handle this. In future versions of npm, I believe this will happen during npm install by default, but as of 1.x and 2.x I think a separate dedupe is required.
Why does, for example, a Grunt plugin define its dependency on grunt as "peer dependencies"?
Why can't the plugin just have Grunt as its own dependency in grunt-plug/node_modules?
Peer dependencies are described here: https://nodejs.org/en/blog/npm/peer-dependencies/
But I don't really get it.
Example
I'm working with AppGyver Steroids at the moment which uses Grunt tasks to build my source files into a /dist/ folder to be served on a local device. I'm quite new at npm and grunt so I want to fully comprehend what is going on.
So far I get this:
[rootfolder]/package.json tells npm it depends on the grunt-steroids npm package for development:
"devDependencies": {
"grunt-steroids": "0.x"
},
Okay. Running npm install in [rootfolder] detects the dependency and installs grunt-steroids in [rootfolder]/node_modules/grunt-steroids.
Npm then reads [rootfolder]/node_modules/grunt-steroids/package.json so it can install grunt-steroids own dependencies.:
"devDependencies": {
"grunt-contrib-nodeunit": "0.3.0",
"grunt": "0.4.4"
},
"dependencies": {
"wrench": "1.5.4",
"chalk": "0.3.0",
"xml2js": "0.4.1",
"lodash": "2.4.1"
},
"peerDependencies": {
"grunt": "0.4.4",
"grunt-contrib-copy": "0.5.0",
"grunt-contrib-clean": "0.5.0",
"grunt-contrib-concat": "0.4.0",
"grunt-contrib-coffee": "0.10.1",
"grunt-contrib-sass": "0.7.3",
"grunt-extend-config": "0.9.2"
},
The "dependencies" packages are installed into [rootfolder]/node_modules/grunt-steroids/node_modules which is logical for me.
The "devDependencies" aren't installed, which I'm sure is controlled by npm detecting I'm just trying to use grunt-steroids, and not develop on it.
But then we have the "peerDependencies".
These are installed in [rootfolder]/node_modules, and I don't understand why there and not in [rootfolder]/node_modules/grunt-steroids/node_modules so that conflicts with other grunt plugins (or whatever) are avoided?
TL;DR: peerDependencies are for dependencies that are exposed to (and expected to be used by) the consuming code, as opposed to "private" dependencies that are not exposed, and are only an implementation detail.
The problem peer dependencies solve
NPM's module system is hierarchical. One big advantage for simpler scenarios is that when you install an npm package, that package brings its own dependencies with it so it will work out of the box.
But problems arise when:
Both your project and some module you are using depend on another module.
The three modules have to talk to each other.
In Example
Let's say you are building YourCoolProject and you're using both JacksModule 1.0 and JillsModule 2.0. And let's suppose that JacksModule also depends on JillsModule, but on a different version, say 1.0. As long as those 2 versions don't meet, there is no problem. The fact that JacksModule is using JillsModule below the surface is just an implementation detail. We are bundling JillsModule twice, but that's a small price to pay when we get stable software out of the box.
But now what if JacksModule exposes its dependency on JillsModule in some way. It accepts an instance of JillsClass for example... What happens when we create a new JillsClass using version 2.0 of the library and pass it along to jacksFunction? All hell will break loose! Simple things like jillsObject instanceof JillsClass will suddenly return false because jillsObject is actually an instance of another JillsClass, the 2.0 version.
How peer dependencies solve this
They tell npm
I need this package, but I need the version that is part of the
project, not some version private to my module.
When npm sees that your package is being installed into a project that does not have that dependency, or that has an incompatible version of it, it will warn the user during the installation process.
When should you use peer dependencies?
When you are building a library to be used by other projects, and
This library is using some other library, and
You expect/need the user to work with that other library as well
Common scenarios are plugins for larger frameworks. Think of things like Gulp, Grunt, Babel, Mocha, etc. If you write a Gulp plugin, you want that plugin to work with the same Gulp that the user's project is using, not with your own private version of Gulp.
I would recommend you to read the article again first. It's a bit confusing but the example with winston-mail shows you the answer why:
For example, let's pretend that winston-mail#0.2.3 specified "winston": "0.5.x" in its "dependencies" object because that's the latest version it was tested against. As an app developer, you want the latest and greatest stuff, so you look up the latest versions of winston and of winston-mail and put them in your package.json as
{
"dependencies": {
"winston": "0.6.2",
"winston-mail": "0.2.3"
}
}
But now, running npm install results in the unexpected dependency graph of
├── winston#0.6.2
└─┬ winston-mail#0.2.3
└── winston#0.5.11
In this case, it is possible to have multiple versions of a package which would cause some issues. Peer dependencies allow npm developers to make sure that the user has the specific module (in the root folder). But you're correct with the point that describing one specific version of a package would lead to issues with other packages using other versions. This issue has to do with npm developers, as the articles states
One piece of advice: peer dependency requirements, unlike those for regular dependencies, should be lenient. You should not lock your peer dependencies down to specific patch versions.
Therefore developers should follow semver for defining peerDependencies. You should open an issue for the grunt-steroids package on GitHub...
peerDependencies explained with the simplest example possible:
{
"name": "myPackage",
"dependencies": {
"foo": "^4.0.0",
"react": "^15.0.0"
}
}
{
"name": "foo"
"peerDependencies": {
"react": "^16.0.0"
}
}
running npm install in myPackage will throw an error because it is trying to install React version ^15.0.0 AND foo which is only compatible with React ^16.0.0.
peerDependencies are NOT installed.