I think I’ve found out what’s going on. Indeed, looks like a bug in
I’ll submit a pull request with a fix shortly I’ve submitted a pull request.
I found that the NPM cache was influencing the ability to reproduce this bug (if the package was installed on a new machine with
npm install for the first time, then subsequent
npm ci would use the cached package, which had already run the
prepare script). On machines that installed the package for the first time with
npm ci, the
prepare script was never run.
The issue can be reproduced in email@example.com with the following steps:
npm install <git module with prepare script>
npm cache clean --force
Within the NPM CLI, the
pacote config returned from
lib/config/pacote.js contains a
dirPacker key whose value points to the
packGitDep function from
lib/pack.js. Under a normal npm install, everything works as expected, but for
npm ci, the value for
dirPacker is undefined. The reason for this is due to a bug with
child() function within this file accepts an
opts parameter, and overwrites the returned pacote configuration’s
dirPacker with the value from the
opts parameter. When
pacote configuration for
dirPacker is overwritten with
child() function, if
opts.dirPacker is undefined, don’t overwrite the configuration returned from
toPacote. I’ve confirmed that making this change has solved the issue.
I’ll submit a pull request shortly and will update this post when the pull request is up. Pull request submitted.
Is there a good way to add tests that can prevent regressions against this in the future? I don’t see a good way to add tests to
libcipm, but maybe I’m missing something.