cordova-cli
cordova-cli copied to clipboard
apache
Add missing npm-shrinkwrap.json
We had this file in Cordova 8 but must have missed it for the release of Cordova 9. As discussed before, this is important to make the release immutable.
This is a patch-level change
Doesn't this actually end up causing more problems than it solves though? For example, when we released a patch for cordova-lib 9.0.1, it was immediately available to everyone. With shrinkwrap we'd need to then make a new patch release of the CLI as well?
@dpogue What you say is true, we would have to do an additional release. But I think it would be preferable to know exactly which dependencies a user's Cordova installation has. I find it quite irritating. That the bugs we had in [email protected] are now fixed in [email protected]. Kind of defeats the purpose of versioning.
I don't even know what upgrade instructions I should give a user. npm i -g cordova@latest? I have no idea if that will install the latest dependencies for an already installed cordova@latest. My best guess would be that it rather does nothing at all. So we'd need to tell them to run npm un -g cordova && npm i -g cordova I guess.
A drawback would be the fix release turn around time.
Using the same example, if
[email protected]was released with a fix, we must wait for about 1 (discuss) + 2 (vote) days before it is publicly released. Adding the shrinkwrap will now increase this 2 to 3 days release time to 5 to 6 days as we must perform the same process forcordova-cli.
If we would be using release candidate versions (like 10.0.0-rc.1) then we could do the releases simultaneously and this wouldn't apply, right?
Do we still need this PR since we ship a package-lock.json file?
Yes. In fact npm-shrinkwrap.json would replace package-lock.json. In contrast to the latter, the former is distributed with packages and used when installing them. Thus it is intended for CLI packages etc. For more details see https://docs.npmjs.com/files/shrinkwrap.json
Like discussed above, this would have the benefit of actually freezing a release and the drawback of increased bugfix turnaround time, given our release process
As much as I don't like package lock & shrink-wrap files, this would probably have prevented issue #543.
