bestander
package.json different but node_modules the same except for supposed EOL changes
I have encountered some behavior that I'm not sure how to work around.
I have npm-git-lock included as part of my build process via the following 2 npm scripts:
"gitlock": "npm-git-lock --repo https://repo-url-here.git --verbose --cross-platform --incremental-install",
"start": "npm run gitlock && grunt"
The issue I have just encountered is that I updated package.json, and so per https://github.com/bestander/npm-git-lock#how-it-works, npm-git-lock begins with step 1 and goes through to step 5, where it fails at the commit I think because npm-git-lock tries to commit node_modules even though the node_modules content in the remote repo is actually identical to the node_modules content that npm-git-lock is trying to commit, hence there is nothing to commit. This seems to be because, the change to the package.json was just the addition of a package that was already previously installed and committed to the remote repo because it was a dependency of a package that was included in package.json at the time of a previous execution of the npm-git-lock command.
Since step 5 results in an error with exit code 1, my npm start script fails.
It looks like https://github.com/bestander/npm-git-lock/blob/master/src/checkout-node-modules.es6#L331 is already checking whether there are any local changes, and when I run git status in the git repo that npm-git-lock clones within node_modules, it does show some files have been modified, but the modifications are only end-of-line changes which disappear when the files are staged. So I believe gitHasChanges is returning true due to the EOL modification warnings, but then the commit ultimately fails due to the line ending modifications disappearing during staging....
Any advice on how to deal with this issue would be much appreciated!
Hey @galvarez421. I think this edge case should be handled because adding a tag of package.json sha1 is unconditional. But there can be an error thrown by git somewhere that is not handled by this tool. Would be great if you could debug and send a PR.
As an alternative, have a look if Yarn would be a better fit for your CI https://yarnpkg.com/blog/2016/11/24/offline-mirror/
@bestander Thank you for the link, it looks like yarn is a good alternative to consider!
As for the issue I reported, I will continue looking into it. I tried to reproduce the issue on a different machine but was unable to, so I'll continue trying to reproduce the issue for now.