lirantal / lockfile-lint

Lint an npm or yarn lockfile to analyze and detect security issues
Apache License 2.0
780 stars 35 forks source link

Ability to validate lockfileVersion #128

Closed appsbytom closed 2 years ago

appsbytom commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Very true, thanks again for the suggestions 😄

lirantal commented 2 years ago

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