I contribute to a project where users use both NPM, and YARN. NPM generates package-lock.json, and yarn generates yarn-lock.json both use package.json.
I know that yarn import can be used to use package-lock.json, but then if there's a dependency installed with yarn, then there is no way to update package-lock.json from yarn as far as I know.
So in other words if a PR uses NPM, yarn-lock won't be up to date, and if a PR uses Yarn, package-lock won't be up to date. Then if another later PR comes in those lock files will come in as if they changed when in reality they weren't updated previously just because the previous sentence statement.
I don't like to use "best practice", because is all relative to each person experience, but do anyone has any tips in this scenario. Is it best just to not commit both lock files? Is there another system that works best, or is it just best to force users to use yarn or npm? I think users should just use whatever they want.
Top comments (5)
I would force either NPM or Yarn, and commit lock file.
I have seen a scenario where code won't run because of exact version mismatch.
I know it is silly, but it is also as silly as indentation and prettier settings.
Yeah I think forcing one package manager might be the best solution, I don't see any sane way to keep both lock files in sync. There is a few solutions for syncing yarn-lock but none for package-lock that I could find if you use yarn.
If it's a library, do not commit lockfile, because your dependents would not respect your lockfile.
If it's an end application, force one package manager only: npmjs.com/package/only-allow
Nice, that looks like a nice package! Thanks for the suggestion!
I mix it a lot because sometimes I get an error when instaling packages with npm and it works wel