gbv/wikidata-jskos

Failing to write MSC mapping

Closed this issue · 2 comments

nichtich commented

Tested with this mapping. May also be a configuration error?

stefandesu commented

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:

  1. Include package-lock.json in this repo.
  2. 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.
  3. 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.

Relevant post on StackOverflow: https://stackoverflow.com/a/56254478

nichtich commented
  • 👍1