Npm5 introduced proper lock files. Now the node_module
should be 100% reproducible.
But these new files also add pitfalls and problems. Which ones did you encounter and how did you solve it?
Npm5 introduced proper lock files. Now the node_module
should be 100% reproducible.
But these new files also add pitfalls and problems. Which ones did you encounter and how did you solve it?
I’ll start (of course, otherwise I wouldn’t have created this thread):
It will take quite some time to remember to delete the lock file before running npm install
when something in package.json
was changed manually or node_modules
was just broken. If you forget this, npm install
will just do exactly what it did the last time, which was probably broken. Alternative: Never edit package.json
manually (yeah, right…).
I think I’m going to give this option a try, and try to confine myself to allowing npm install
to manage package.json
.
Just found this in the docs:
--no-shrinkwrap
argument, which will ignore an available
package lock or shrinkwrap file and use the package.json instead.
I can’t tell from that description whether the lock/shrinkwrap file is updated with the result. If it’s not, then it would seem that use of that argument will result in the lock files getting out of sync with reality, with the result that any clones of the repo will not get the desired versions of things.
Right, I assumed it to do that - otherwise this option would be pretty dangerous. Will have to test (or find another way to handle things. Because that param will be forgotten…).
I had problem with a webpack error (https://github.com/ionic-team/ionic-app-scripts/issues/1066) which had to be solved by deleting the package-lock.json file before reinstalling everything and regenerating that file. not sure what happens. at least seems that if you delete the file and run a new npm install, the all package-lock.json gonna be generated again with the new entries
For the time being i’m going with the .npmrc file.
Is there a command that checks if package.json
and package-lock.json
match?
Does the introduction of package-lock.json means that libs could only now be updated via cmd “npm update …”?
To update libs I often change the version number in package.json and then remove node_modules and reinstall everything. Maybe in such case package-lock.json doesn’t notice the update and would end up in an out of sync state
I just landed on another weird stuff…I wanted to update to the last plugin of calendar. I had locally 4.5.5 and wanted to upgrade to 4.6.0, so I did:
ionic cordova plugin rm cordova-plugin-calendar
ionic cordova plugin add cordova-plugin-calendar
everything went fine. I compared then the local changes with git and noticed that only config.xml and package.json were updated (displaying the change 4.5.5 -> 4.6.0)
I opened then package-lock.json to find out what what there specified and it turns out that this file already contained the last version 4.6.0
The means that if I check Git I’ve got:
package.json -> 4.5.5
config.xml -> 4.5.5
package-lock.json -> 4.6.0
Isn’t that weird?
Yes, the “reinstall everything” part being running npm install
would just use the package-lock.json again and install the same stuff that you just deleted. You can either delete package-lock.json together with node_modules, or run npm install --no-shrinkwrap
so that it explicitly uses package.json as the source of truth.
That would be weird, and would probably also mean you already had 4.5.5 installed - because package-lock.jon is a representation of the exact state of node_modules. To contrast package.json is a representation of “idtent” to install stuff. Are you 100% sure package-lock wasn’t edited when running these commands as well?
I’m 100% sure, GIT didn’t displayed any differences
Thx for clearing my question about “update”, understood better now
@Sujan12 I just published my app, therefore before and after building it, I removed/added the plugin console
ionic cordova plugin rm cordova-plugin-console
ionic cordova plugin add cordova-plugin-console
following that, only config.xml and package.json where updated aka displayed a Git difference, package-lock.json stay the same. May that explain the weird effect I explained above? “…cordova plugin rm/add…” maybe doesn’t update package-lock.json?
That would not be good. But of course possible, when Cordova changed to package.json npm5 wasn’t a thing yet so they surely didn’t test that.
Hmm, normally the cordova
command run internally should execute with --save
and npm5 do --save
by default anyway.
Can you run the same commands with --verbose
and see what exact cordova
command is executed and if this outputs something useful to how it does the npm stuff?
Also try running the commands without ionic
in front but with --debug
at the end, again looking at the output.
Thx for answer and tips. Tried again with all the debug information and the output was ok. Then I did a rm again and add a look at the content of package-lock.json and I didn’t saw the plugin, what was correct. Run the add cmd and again add a look at package-json.lock and the plugin was there again.
I then figured out why I noticed a difference with Git.
Look like package-json.lock is always sorted alphabetically, “removing/adding a plugin remove/add lines at the same place”, where adding a plugin in config.xml always gonna add the plugin at the end of the file and in package.json at the end of the cordova section, therefore I only noticed differences for these two files.
Again thx for the comment, sorry for loosing your time
Nah, we clarified something here - no problem with package-lock and Cordova plugins - that’s great.
npm5.1 is out and there is some stuff relevant to what we discussed:
Release v5.1.0 · npm/npm · GitHub
47e8fc8eb #17508 Make
npm ls
take package locks (and shrinkwraps) into account. This means npm ls can now be used to see which dependencies are missing, so long as a package lock has been previously generated with it in. (@iarna)
Most important:
f0075e7ca #17508 Take
package.json
changes into account when running installs – if you remove or add a dependency topackage.json
manually, npm will now pick that up and update your tree and package lock accordingly. (@iarna)
If that works as I understand it, this removes the requirement to delete package-lock.json
manually before running npm install
.
Also:
a1058afd9 #17169 Document
--no-package-lock
flag. (@leggsimon)
Ummm not sure that work for dev dependencies. Yesterday had problem while upgrading app-scripts to 2.0.0, had to remove package-lock.json
before removing node_modules
and installing everything again to solve it