Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to validate lockfileVersion #128

Closed
appsbytom opened this issue Jun 8, 2022 · 7 comments
Closed

Ability to validate lockfileVersion #128

appsbytom opened this issue Jun 8, 2022 · 7 comments
Assignees
Labels
enhancement New feature or request

Comments

@appsbytom
Copy link

appsbytom commented Jun 8, 2022

Is your feature request related to a problem? Please describe.
Using npm in a team has the ability for different engineers to install different npm versions, these different versions can change the lockfileVersion field as the schema changes https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-json#lockfileversion

Describe the solution you'd like
A flag to pass the version it should be and it validates the real version match.

Describe alternatives you've considered
Please describe alternative solutions or features you have considered.

Notes
Yarn does not have this field but instead has a comment https://classic.yarnpkg.com/lang/en/docs/yarn-lock/. This could be an npm only feature?
Would require changing the format returned from parsing so not just a list of dependencies is returned

@lirantal lirantal self-assigned this Jun 8, 2022
@lirantal lirantal added the enhancement New feature or request label Jun 8, 2022
@lirantal
Copy link
Owner

lirantal commented Jun 8, 2022

Totally understand where this is helpful to force a specific one version for the team, but I think this shouldn't be done with lockfile-lint, but rather with something like nvm's .nvmrc (see here: https://github.com/nvm-sh/nvm#nvmrc) or if you use fnm then the corresponding config.

Does that make sense?

@appsbytom
Copy link
Author

I see what you mean with .nvmrc however that doesn't force the version as the developer needs to remember to run nvm use. So it's possible if the developer uses a different default Node version to what the project uses it can be missed.
Also using a specific Node version doesn't always mean that the npm versions are the same.

Current example is, I use the default npm version with Node 10 however a team member had upgraded to the latest npm while still on Node 10. This meant I was on lockfileVersion 1 and they were on 2

@lirantal
Copy link
Owner

lirantal commented Jun 8, 2022

lockfileVersion 2 is actually backwards compatible with lockfileVersion 1 :-)

So, some ideas for other workarounds that can apply here:

  1. You can specify the Node.js runtime versions, and also the npm runtime version with package.json's engines field. See here
  2. You can also explicitly have a .npmrc file with a lockfile-version configuration setting to force it.

Any of this is helpful?

@appsbytom
Copy link
Author

It may be compatible but we had the issue of the package-lock rewriting itself to match the correct schema for the npm version used and switching back and forth. So wanted to have something that would automatically flag this.

lockfile-version in .npmrc is a good idea though, thanks.

Looking more at .npmrc, wouldn't the registry key do similar as to the checks here for hosts, https?

@lirantal
Copy link
Owner

lirantal commented Jun 8, 2022

lockfile-version in .npmrc is a good idea though, thanks.

🤗

Looking more at .npmrc, wouldn't the registry key do similar as to the checks here for hosts, https?

Nope. It doesn't force a trust policy, but merely sets the default upstream repository for when you do npm install.

@appsbytom
Copy link
Author

Very true, thanks again for the suggestions 😄

@appsbytom appsbytom closed this as not planned Won't fix, can't repro, duplicate, stale Jun 8, 2022
@lirantal
Copy link
Owner

lirantal commented Jun 8, 2022

Anytime!
Thank you for bringing this up and brainstorming with us ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants