Closed nichtich closed 4 years ago
If you had tried any other mapping, or looked at the network response, you would have seen that it was an issue with our instance. First of all, I temporarily fixed it by installing the dependencies on our instance and restarting it. Here's the problem:
package-lock.json
is not included in this repositorypackage-lock.json
file; if there is one, it will run npm ci
, if there isn't one, it will run npm install
package-lock.json
file is not committed in this repo, it will still be generated when running npm install
, so at some point, our update script did that and we had a package-lock.json
filenpm ci
; but because the package-lock.json
is not committed in the repository, the package-lock.json
was not in sync with package.json
and npm refused to install dependenciesI see three different possibilities to fix this:
package-lock.json
in this repo.npm install
is used always, or that it checks whether package-lock.json
is part of the repo and uses that to decided whether to use npm install
or npm ci
.npm install --no-package-lock
on the server so that a package-lock.json
is never generated.I'm voting for 1. package-lock.json
is intended to be included in source control by design. The arguments against using it are either not convincing or only refer to packages that are used as dependencies by other applications (so it doesn't apply to wikidata-jskos). I'm voting for including the file and always using npm ci
to install dependencies, except if the purpose is to update the dependencies (because then the updated package-lock.json
will be committed).
I will still implement 3. because it fixes the immediate problem, but I'm also voting for 1. for all our projects. We have the package-lock.json
file in source control in most of our repos anyway.
Relevant post on StackOverflow: https://stackoverflow.com/a/56254478
OK, include package-lock.json
and make sure the docs tell to use nmp ci
Tested with this mapping. May also be a configuration error?