Closed HoffmannThomas closed 3 years ago
Thank you for digging out that issue on npm/npm! I did a quick test and find this very promising.
From my understanding we can basically remove all devDependencies from the npm-shrinkwrap.json using:
npm install
- Installs all dependencies (dev- and non-dev) into node_modules
npm prune --production
- Removes all devDependencies from node_modules
npm shrinkwrap
- Updates npm-shrinkwrap.json
based on content of node_modules
Or even quicker:
npm install --production
npm shrinkwrap
In the first scenario I find it weird that npm shrinkwrap
still needs to be executed. npm states in their documentation:
any commands that update node_modules and/or package.json’s dependencies will automatically sync the existing lockfile.
Yet somehow npm prune
seems to be an exception to this.
Also, the npm shrinkwrap
documentation does not mention anything on updating it based on the node_modules
directory content.
Anyways, it seems to work 🤷♂
So, since we want to have locked devDependencies while working on the UI5 CLI project, we can only remove them from the npm-shrinkwrap.json
that is going to be published to the npm registry. I guess we can give this a shot.
During release, after the tests have been executed and the version bump is complete (which creates a commit that should not change the shrinkwrap), we can remove all devDependencies (npm prune --production
) and update the shrinkwrap (npm shrinkwrap
) right before publishing.
I'll update our internal release script. This will probably be in place for UI5 CLI v2.0.
The change got implemented into our release script. We'll see the effect with the next release 👍
Okay, so the proposed change was in place when we published @ui5/cli@2.0.0. However, a pretty interesting side-effect caused our CI to produce and publish a corrupt npm-shrinkwrap.json
. We were able to publish a corrected 2.0.1 from my local machine shortly after but only now I got around to look into the root cause of the corruption during our CI build.
I found that npm test
in our case will cause esm
to create a couple of .cache
directories within node_modules/
. They are not removed by npm prune --production
, even though the module containing them is pruned. Because of that, npm shrinkwrap
will generate npm-shrinkwrap.json
entries like "ava": {}
and "esm": {}
. When installing from that npm-shrinkwrap.json
, npm will throw an error Cannot read property 'match' of undefined
.
Our workaround is to execute npm ci
again after npm test
since that will remove the node_modules
directory completely before installing all dependencies again. We will also add a validation step using npm pack
and a test install of the generated tar before the final publish.
Our workaround is to execute npm ci again after npm test since that will remove the node_modules directory completely before installing all dependencies again. We will also add a validation step using npm pack and a test install of the generated tar before the final publish.
This has been done and the release of v2.0.2 worked like a charm 🎉
❯ npm i @ui5/cli@latest
+ @ui5/cli@2.0.2
added 588 packages from 377 contributors and audited 8277 packages in 7.566s
found 0 vulnerabilities
Thanks again for reporting this issue!
Followup to https://github.com/SAP/ui5-cli/issues/282
Might be related to https://github.com/npm/npm/issues/11189
Potential solution: https://github.com/npm/npm/issues/11189#issuecomment-223770995
Expected Behavior
npm ls
passesCurrent Behavior
Steps to reproduce the issue
Context
ui5 --version
when using the CLI):1.14.0
any
6.14.2
Windows
Affected components (if known)