This was the cause for #58 and I'm copy-pasting my reply here as a separate issue:
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 repository
our instance gets updated automatically with every commit on master on this repo
during the update, the script looks for a package-lock.json file; if there is one, it will run npm ci, if there isn't one, it will run npm install
while the 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 file
so on the next update, the script detected that file and ran npm 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 dependencies
this caused an issue with our dependencies on the server and all requests failed
I see three different possibilities to fix this:
Include package-lock.json in this repo.
Adjust our server so that either 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.
Use 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.
This was the cause for #58 and I'm copy-pasting my reply here as a separate issue:
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.jsonis not included in this repositorypackage-lock.jsonfile; if there is one, it will runnpm ci, if there isn't one, it will runnpm installpackage-lock.jsonfile is not committed in this repo, it will still be generated when runningnpm install, so at some point, our update script did that and we had apackage-lock.jsonfilenpm ci; but because thepackage-lock.jsonis not committed in the repository, thepackage-lock.jsonwas not in sync withpackage.jsonand npm refused to install dependenciesI see three different possibilities to fix this:
package-lock.jsonin this repo.npm installis used always, or that it checks whetherpackage-lock.jsonis part of the repo and uses that to decided whether to usenpm installornpm ci.npm install --no-package-lockon the server so that apackage-lock.jsonis never generated.I'm voting for 1.
package-lock.jsonis 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 usingnpm cito install dependencies, except if the purpose is to update the dependencies (because then the updatedpackage-lock.jsonwill 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.jsonfile in source control in most of our repos anyway.Relevant post on StackOverflow: https://stackoverflow.com/a/56254478