npm outdated
A constant struggle, to be sure.
Steps to reproduce:
- make a fresh
git cloneof the repo. $ npm install.- Post install,
$ npm outdated
Observe: Out of the box, the following packages are lagging. Some significantly.
$ npm outdated
Package Current Wanted Latest Location
babel 6.3.13 6.3.13 6.5.2 state-machine
babel-core 6.1.18 6.1.18 6.18.2 state-machine
babel-eslint 5.0.0 5.0.0 7.1.1 state-machine
babel-loader 6.1.0 6.1.0 6.2.8 state-machine
babel-plugin-add-module-exports 0.1.2 0.1.2 0.2.1 state-machine
babel-preset-es2015 6.3.13 6.3.13 6.18.0 state-machine
chai 3.4.1 3.4.1 3.5.0 state-machine
eslint 1.7.2 1.7.2 3.10.2 state-machine
eslint-loader 1.1.0 1.1.0 1.6.1 state-machine
mocha 2.3.4 2.3.4 3.1.2 state-machine
webpack 1.12.9 1.12.9 1.13.3 state-machine
yargs 3.32.0 3.32.0 6.4.0 state-machine
Aside: This will also eliminate some of the deprecation warnings during $ npm install
Hmmm. As mentioned in another issue, I'm no expert on config and packages.
From what I can tell, it looks like babel-cli wanted to be 6.18.0 (it was 6.16) but I run this a couple of times and I get the same results as above, and not 0 results as in the NPM video on the subject.
Should I be manually updating package.json to these latest versions?
My understanding of things, was if it works at the major/minor version number, leave it alone. Not so?
In a young project I think you want to be on top of this. Manually update package.json, yes.
It's not clear whether you ran npm update – that'll replace the older versions for sure.
Probably advisable to delete the node_modules folder occasionally to perfectly mimic what a fresh clone gets.
I ran npm update but that only updates version to their wanted, not latest versions, right?
You think I should specify them all as ^ until one doesn't work?
Good advice on deleting the node_modules folder periodically as well.
Here's the list of options for prefixing dependencies. I tend to always want the latest utilities, packagers, transpilers and test runners, and a little more conservative on linters.
Note that these are not equivalent. The last one is more liberal, and the one I would pick at this stage.
^ 6.18.0
^ 6.18.x
^ 6.x
Also npm-shrinkwrap is interesting. Here you can have a liberal package.json for development, and lock that down as part of your major release or tagging process.
Yeah, I'm aware of it. Probably as the tasks above are just build and code quality, your first suggestion will be the most appropriate one.
Thanks for all the input BTW!
Another thing to be aware of is your .npmrc file settings, in particular save-exact and save-prefix.