Related
I'm trying to learn node and npm, using express for a little project.
When i install it, i got
npm WARN deprecated core-js#2.6.10: core-js#<3.0 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js#3.
I understood that if everything works, it's not necessary to update everything, but i'm trying to learn and go the extra, unnecessary, mile.
How can i update only core-js?
npm install core-js#^3
will update it adding it to the dependencies in package.json.
Is this the right way to do it?
Or it's better to update the parent package that use it? If so, how can i understand which is the package that need an update and how to update it?
Or is there a way to update only the modules listed in package-lock.json.
Thanks.
You provided one way to update a package. However, there are a few more.
To update a global package, you could run:
npm update -g <package_name>
To update a package that's in your package.json (i.e., local to your project), run:
npm update <package_name>
You could also see what outdated package are there as follows:
npm outdated
You could again add -g option to check outdated global packages.
Sources: https://docs.npmjs.com/updating-packages-downloaded-from-the-registry
Also: man npm may help (in Linux).
To update to a new major version all the packages, install the npm-check-updates package globally:
npm install -g npm-check-updates
this will upgrade all the version hints in the package.json file, to dependencies and devDependencies, so npm can install the new major version.
You are now ready to run the update:
npm update
or npm install
I understand the differences between npm install something and npm install something --save (for anyone wondering, the first one will install the dependency only while the latter will install the dependency and add it to your package.json).
However I do not understand why there is a --save option in the first place. In other words, why would you ever want to install a dependency without adding it to your package.json file? Why is the --save option not default?
A lot of websites/npm modules/SaaS suggest installing their module using npm install something (newrelic is one of them for instance), am I missing something?
Edit: Starting from NPM 5, --save is now on by default.
You would have a scenario such as you need some module to install without adding dependency to package.json file, for ex. you just want to try some module, and not sure you would be really using that module in production or while deploying, so instead adding the module dependency to package.json, just give it a try without using --save. this is why npm install without --save exists.
But For most of your modules you might require using --save, for ex. npm install express --save,
in this case you surely know that you are going to use express for you application.
The other scenario, for not using --save, would be, npm install heapdump or npm install nodemon, I would use it for testing my apps performance, but not add a dependency in the package.json :)
Also, As #surajck said in comment below: when you are doing global installs, in that case adding dependencies using --save, to the package.json would not make sense.
I just learned a nice trick from Jonathan Mills' JavaScript Best Practices course on Pluralsight. From the terminal:
npm config set save=true
Now I don't need to remember --save anymore. And I also now use
npm config set save-exact=true
Because I want the exact version of the package not the ^ prefix.
By default with version npm 5.0+ npm install adds the module to the dependencies list in the package.json file; with earlier versions of npm, you must specify the --save option explicitly. Then, afterwards, running npm install in the app directory will automatically install modules in the dependencies list.
What is the difference between:
npm install [package_name]
and:
npm install [package_name] --save
and:
npm install [package_name] --save-dev
What does this mean? And what is really the effect of --save and -dev keywords?
The difference between --save and --save-dev may not be immediately noticeable if you have tried them both on your own projects. So here are a few examples...
Let's say you were building an app that used the moment package to parse and display dates. Your app is a scheduler so it really needs this package to run, as in: cannot run without it. In this case you would use
npm install moment --save
This would create a new value in your package.json
"dependencies": {
...
"moment": "^2.17.1"
}
When you are developing, it really helps to use tools such as test suites and may need jasmine-core and karma. In this case you would use
npm install jasmine-core --save-dev
npm install karma --save-dev
This would also create a new value in your package.json
"devDependencies": {
...
"jasmine-core": "^2.5.2",
"karma": "^1.4.1",
}
You do not need the test suite to run the app in its normal state, so it is a --save-dev type dependency, nothing more. You can see how if you do not understand what is really happening, it is a bit hard to imagine.
Taken directly from NPM docs docs#dependencies
Dependencies
Dependencies are specified in a simple object that maps a package name
to a version range. The version range is a string that has one or
more space-separated descriptors. Dependencies can also be identified
with a tarball or git URL.
Please do not put test harnesses or transpilers in your dependencies
object. See devDependencies, below.
Even in the docs, it asks you to use --save-dev for modules such as test harnesses.
--save-dev is used to save the package for development purpose.
Example: unit tests, minification..
--save is used to save the
package required for the application to run.
By default, NPM simply installs a package under node_modules. When you're trying to install dependencies for your app/module, you would need to first install them, and then add them to the dependencies section of your package.json.
--save-dev adds the third-party package to the package's development dependencies. It won't be installed when someone runs npm install directly to install your package. It's typically only installed if someone clones your source repository first and then runs npm install in it.
--save adds the third-party package to the package's dependencies. It will be installed together with the package whenever someone runs npm install package.
Dev dependencies are those dependencies that are only needed for developing the package. That can include test runners, compilers, packagers, etc.
Both types of dependencies are stored in the package's package.json file. --save adds to dependencies, --save-dev adds to devDependencies
npm install documentation can be referred here.
--
Please note that --save is now the default option, since NPM 5. Therefore, it is not explicitly needed anymore. It is possible to run npm install without the --save to achieve the same result.
Let me give you an example,
You are a developer of a very SERIOUS npm library which uses different testing libraries to test the package.
Users download your library and want to use it in their code. Do they need to download your testing libraries as well? Maybe you use jest for testing and they use mocha. Do you want them to install jest as well? Just To run your library?
No. right? That's why they are in devDependencies.
When someone does, npm i yourPackage only the libraries required to RUN your library will be installed. Other libraries you used to bundle your code with or testing and mocking will not be installed because you put them in devDependencies. Pretty neat right?
So, Why do the developers need to expose the devDependancies?
Let's say your package is an open-source package and 100s of people are sending pull requests to your package. Then how they will test the package? They will git clone your repo and when they would do an npm i the dependencies as well as devDependencies.
Because they are not using your package. They are developing the package further, thus, in order to test your package they need to pass the existing test cases as well write new. So, they need to use your devDependencies which contain all the testing/building/mocking libraries that YOU used.
A perfect example of this is:
$ npm install typescript --save-dev
In this case, you'd want to have Typescript (a javascript-parseable coding language) available for development, but once the app is deployed, it is no longer necessary, as all of the code has been transpiled to javascript. As such, it would make no sense to include it in the published app. Indeed, it would only take up space and increase download times.
As suggested by #andreas-hultgren in this answer and according to the npm docs:
If someone is planning on downloading and using your module in their program, then they probably don't want or need to download and build the external test or documentation framework that you use.
However, for webapp development, Yeoman (a scaffolding tool that installs a peer-reviewed, pre-written package.json file amongst other things) places all packages in devDependencies and nothing in dependencies, so it appears that the use of --save-dev is a safe bet in webapp development, at least.
--save-dev saves semver spec into "devDependencies" array in your package descriptor file, --save saves it into "dependencies" instead.
--save-dev is used for modules used in development of the application,not require while running it in production environment
--save is used to add it in package.json and it is required for running of the application.
Example: express,body-parser,lodash,helmet,mysql all these are used while running the application use --save to put in dependencies while mocha,istanbul,chai,sonarqube-scanner all are used during development ,so put those in dev-dependencies .
npm link or npm install will also install the dev-dependency modules along with dependency modules in your project folder
Read Complete And Forget --save-dev Headache
Simplest answer is that --save-dev is useful when you are creating packages for other developers and want to host your package at NPM Registry like lodash, mongoose, express etc. When you are building or writing a Node Server there is no difference between --save and --save-dev because your Node Server implementation is private to you and you will never publish it on NPM.
How NPM Install Works
Whenever we install a new package using npm like npm install express then NPM installs that package to our system and put it into node_modules folder, now NPM will analyze the package.json file of newly installed package i.e express in this case, after analyzing NPM will install all those packages which were mentioned in dependencies section of package.json file of express package. After installing those packages on which express was dependent NPM again analyze the package.json file of all newly installed packages and again install the packages for them, this cycle goes on until all packages are available into node_modules folder to function properly. You can check package dependencies by running npm list in terminal where terminal should point location of your project directory.
How --save-dev Is Related To Above Explained Stuff
Suppose you want to create a new package like express, now while development of this new package you probably want to write some unit testing code and test the package with any other available testing package let's assume mocha in this case. Now you know mocha is only required to test the package not required to use the package. In this case you should install mocha using --save-dev flag, otherwise NPM will install it whenever a developer install your package using NPM. So if we want a dependency not installed when someone install our package from NPM we must install that package using --save-dev in development phase.
Last Thing
Do not mix --save-dev with collaboration development, if someone cloned your package code from a source version control system like github then NPM will surely install all devDependencies i.e package installed using --save-dev also.
Clear answers are already provided. But it's worth mentioning how devDependencies affects installing packages:
By default, npm install will install all modules listed as dependencies in package.json . With the --production flag (or when the NODE_ENV environment variable is set to production ), npm will not install modules listed in devDependencies .
See: https://docs.npmjs.com/cli/install
When you install an npm package using npm install <package-name>, you are installing it as a dependency.
The package is automatically listed in the package.json file, under the dependencies list (as of npm 5: before you had to manually specify --save).
ex. npm install lodash
After pressing enter check your package.json file.
"dependencies": {
"lodash": "4.x",
},
When you add the -D flag, or --save-dev, you are installing it as a development dependency, which adds it to the devDependencies list.
ex. npm install --save-dev lite-server
After pressing enter check your package.json file
"devDependencies": {
"lite-server": "^2.6.1"
},
Development dependencies are intended as development-only packages, that are unneeded in production. For example testing packages, webpack, or Babel.
When you go in production, if you type npm install and the folder contains a package.json file, they are installed, as npm assumes this is a development deploy.
You need to set the --production flag (npm install --production) to avoid installing those development dependencies.
All explanations here are great, but lacking a very important thing: How do you install production dependencies only? (without the development dependencies).
We separate dependencies from devDependencies by using --save or --save-dev.
To install all we use:
npm i
To install only production packages we should use:
npm i --only=production
You generally don't want to bloat production package with things that you only intend to use for Development purposes.
Use --save-dev (or -D) option to separate packages such as Unit Test frameworks (jest, jasmine, mocha, chai, etc.)
Any other packages that your app needs for Production, should be installed using --save (or -S).
npm install --save lodash //prod dependency
npm install -S moment // " "
npm install -S opentracing // " "
npm install -D jest //dev only dependency
npm install --save-dev typescript //dev only dependency
If you open the package.json file then you will see these entries listed under two different sections:
"dependencies": {
"lodash": "4.x",
"moment": "2.x",
"opentracing": "^0.14.1"
},
"devDependencies": {
"jest": "22.x",
"typescript": "^2.8.3"
},
--save-dev (only used in the development, not in production)
--save (production dependencies)
--global or -g (used globally i.e can be used anywhere in our local system)
People use npm on production to do wicked cool stuff, Node.js is an example of this, so you don't want all your dev tools being run.
If you are using gulp (or similar) to create build files to put on your server then it doesn't really matter.
Basically We Write
npm install package_name
But specially for Testing Purpose we don't need to run some package while Application is Running in Normal State so that Node introduce good way to solve this problem. Whenever we write
npm install package_name --save-dev
at that time this package is only installed for development purpose.
I want to add some of my ideas as
I think all differences will appear when someone uses your codes instead of using by yourself
For example, you write an HTTP library called node's request
In your library,
you used lodash to handle string and object, without lodash, your codes cannot run
If someone uses your HTTP library as a part of his code. Your codes will be compiled with his.
your codes need lodash, So you need to put in dependencies to compile
If you write a project like monaco-editor, which is a web editor,
you have bundled all your codes and your product env library using webpack, when build completed, only have a monaco-min.js
So someone doesn't care whether --save or --save-dependencies, only he needs is monaco-min.js
Summary:
If someone wants to compile your codes (use as a library),
put lodash which used by your codes into dependencies
If someone want to add more feature to your codes, he needs unit test and compiler, put these into dev-dependencies
as --save is default option for npm, so I use
npm i package
and for --save-dev, I use
npm i package -D
default option will install package as project dependency where as -D is for development dependencies like testing, lint etc. and install package for development process
you can find all the flags here https://docs.npmjs.com/cli/v8/commands/npm-install
After npm init I can add dependencies in my package.json using this:
npm install package --save
And say, I want to uninstall the package and I do so by doing:
npm uninstall package
but I want my package.json to be updated accordingly too without me having to manually go to the file and delete that line.
From the npm docs it says:
It is strictly additive, so it does not delete options from your package.json without a really good reason to do so.
So, I just wanted to know if this is even possible.
Use the same --save flag. If you installed a dependency with:
$> npm install grunt-cli --save
you can uninstall it, with package.json getting updated, using:
$> npm uninstall grunt-cli --save
The 'save' flag tells npm to update package.json based on the operation you just made it do.
In my case --save did not clear the entry from package.json, the command as suggested by ionic-check I think if the uninstall happens to exit with any errors package.json will not be updated in which case you only have an option to manually change package.json, this is tedious but the only way I guess
UPDATE
when you uninstall a package which has a dependency on other package which is active then which case uninstall may fail with errors/warnings, the safe method is through following dependency graph not sure if there any tool available, a handy tool under such operations, warning messages are quite misleading though "you must install peer dependencies.." doesn't make any sense when we are uninstalling a package
We need to integrate Karma test runner into TeamCity and for that I'd like to give sys-engineers small script (powershell or whatever) that would:
pick up desired version number from some config file (I guess I can put it as a comment right in the karma.conf.js)
check if the defined version of karma runner installed in npm's global repo
if it's not, or the installed version is older than desired: pick up and install right version
run it: karma start .\Scripts-Tests\karma.conf.js --reporters teamcity --single-run
So my real question is: "how can one check in a script, if desired version of package installed?". Should you do the check, or it's safe to just call npm -g install everytime?
I don't want to always check and install the latest available version, because other config values may become incompatible
To check if any module in a project is 'old':
npm outdated
'outdated' will check every module defined in package.json and see if there is a newer version in the NPM registry.
For example, say xml2js 0.2.6 (located in node_modules in the current project) is outdated because a newer version exists (0.2.7). You would see:
xml2js#0.2.7 node_modules/xml2js current=0.2.6
To update all dependencies, if you are confident this is desirable:
npm update
Or, to update a single dependency such as xml2js:
npm update xml2js
To update package.json version numbers, append the --save flag:
npm update --save
npm outdated will identify packages that should be updated, and npm update <package name> can be used to update each package. But prior to npm#5.0.0, npm update <package name> will not update the versions in your package.json which is an issue.
The best workflow is to:
Identify out of date packages with npm outdated
Update the versions in your package.json
Run npm update to install the latest versions of each package
Check out npm-check-updates to help with this workflow.
Install npm-check-updates with npm i npm-check-updates -g
Run npm-check-updates to list what packages are out of date (basically the same thing as running npm outdated)
Run npm-check-updates -u to update all the versions in your package.json (this is the magic sauce)
Run npm update as usual to install the new versions of your packages based on the updated package.json
There is also a "fresh" module called npm-check:
npm-check
Check for outdated, incorrect, and unused dependencies.
It also provides a convenient interactive way to update the dependencies with npm-check -u.
One easy step:
$ npm i -g npm-check-updates && ncu -u && npm i
That is all. All of the package versions in package.json will be the latest major versions.
Edit:
What is happening here?
Installing a package that checks updates for you.
Use this package to update all package versions in your package.json (-u is short for --updateAll).
Install all of the new versions of the packages.
To update a single local package:
First find out your outdated packages by:
npm outdated
Then update the package or packages that you want manually as:
npm update --save <package_name>
This way it is not necessary to update your local package.json
file manually.
Note that the above command will update your package to the latest version.
If you write some version in your package.json file and do:
npm update <package_name>
In this case you will get just the next stable version (wanted) regarding the version that you wrote in your package.json file.
And with npm list <package_name> you can find out the current version of your local package.
You can try either of these options:
Check outdated packages
npm outdated
Check and pick packages to update
npx npm-check -u
No additional packages, to just check outdated and update those which are, this command will do:
npm install $(npm outdated | cut -d' ' -f 1 | sed '1d' | xargs -I '$' echo '$#latest' | xargs echo)
NPM commands to update or fix vulnerabilities in some dependency manifest files
Use below command to check outdated or vulnerabilities in your node modules.
npm audit
If any vulnerabilities found, use below command to fix all issues.
npm audit fix
If it doesn't work for you then try
npm audit fix -f, this command will almost fix all vulnerabilities. Some dependencies or devDependencies are locked in package-lock.json file, so we use -f flag to force update them.
If you don't want to use force audit fix then you can manually fix your dependencies versions by changing them in package-lock.json and package.json file. Then run
npm update && npm upgrade
When installing npm packages (both globally or locally) you can define a specific version by using the #version syntax to define a version to be installed.
In other words, doing:
npm install -g karma#0.9.2
will ensure that only 0.9.2 is installed and won't reinstall if it already exists.
As a word of a advice, I would suggest avoiding global npm installs wherever you can. Many people don't realize that if a dependency defines a bin file, it gets installed to ./node_modules/.bin/. Often, its very easy to use that local version of an installed module that is defined in your package.json. In fact, npm scripts will add the ./node_modules/.bin onto your path.
As an example, here is a package.json that, when I run npm install && npm test will install the version of karma defined in my package.json, and use that version of karma (installed at node_modules/.bin/karma) when running the test script:
{
"name": "myApp",
"main": "app.js",
"scripts": {
"test": "karma test/*",
},
"dependencies": {...},
"devDependencies": {
"karma": "0.9.2"
}
}
This gives you the benefit of your package.json defining the version of karma to use and not having to keep that config globally on your CI box.
As of npm#5.0.0+ you can simply do:
npm update <package name>
This will automatically update the package.json file. We don't have to update the latest version manually and then use npm update <package name>
You can still get the old behavior using
npm update --no-save
(Reference)
A different approach would be to first uprade the package.json file using,
ncu -u
and then simply run,
npm install
to update all the packages to the latest version.
ps: It will update all the packages to the latest version however if the package is already up to date that package will not be affected at all.
3 simple steps you can use for update all outdated packages
First, check the packages which are outdated
sudo npm i -g npm-check-updates
Second, put all of them in ready
ncu -u
Results in Terminal will be like this:
Third, just update all of them.
npm install
That's it.
Just do this to update everything to the latest version -
npx npm-check-updates -u
Note - You'll be prompted to install npm-check-updates. Press y and enter.
Now run npm i. You're good to go.
To really update just one package install NCU and then run it just for that package. This will bump to the real latest.
npm install -g npm-check-updates
ncu -f your-intended-package-name -u
You can do this completely automatically in 2022
Install npm-check-updates
Run the command
ncu --doctor -u
It will first try every dependency you have and run tests, if the tests fail it will update each dependency one by one and run tests after each update
One more for bash:
npm outdated -parseable|cut -d: -f5|xargs -L1 npm i
I'm just interested in updating the outdated packages using the semantic versioning rules in my package.json.
Here's a one-liner that takes care of that
npm update `npm outdated | awk '{print $1}' | tr '\n' ' '`
What it does:
takes the output from npm outdated and
pipes that into awk where we're grabbing just the name of the package (in column 1)
then we're using tr to convert newline characters into spaces
finally -- using backticks -- we're using the output of the preceding steps as arguments to npm update so we get all our needed updates in one shot.
One would think that there's a way to do this using npm alone, but it wasn't here when I looked, so I'm just dropping this here in case it's helpful to anyone 😀.
** I believe there's an answer that MikeMajara provides here that does something similar, but it's appending #latest to the updated package name, which I'm not really interested in as a part of my regularly scheduled updates.
If you want to upgrade a package to the latest release, (major, minor and patch), append the #latest keyword to the end of the package name, ex:
npm i express-mongo-sanitize#latest
this will update express-mongo-sanitize from version 1.2.1 for example to version 2.2.0.
If you want to know which packages are outdated and which can be updated, use the npm outdated command
ex:
$ npm outdated
Package Current Wanted Latest Location Depended by
express-rate-limit 3.5.3 3.5.3 6.4.0 node_modules/express-rate-limit apiv2
helmet 3.23.3 3.23.3 5.1.0 node_modules/helmet apiv2
request-ip 2.2.0 2.2.0 3.3.0 node_modules/request-ip apiv2
validator 10.11.0 10.11.0 13.7.0 node_modules/validator apiv2
If you have multiple projects with the same node-modules content, pnpm is recommended. This will prevent the modules from being downloaded in each project. After the installation the answer to your question is:
pnpm up