Opting out of backwards compatibility of package-lock.json

[valtlai]

I have a project where I only need to support npm v7, so I don’t need backwards compatibility with the earlier versions of npm. I would like to tell npm not to write the top-level dependencies section in package-lock.json. That would nearly halve the file size.

I have two possibilities in mind:

• Adding a new option. I could set it in my project’s .nvmrc file and npm would stop writing the dependencies section.
• Respecting lockfileVersion: 3 that I have manually put in the package-lock.json. (Currently, it’s changed back to lockfileVersion: 2 when running npm update, for example.)

The idea is that you could opt out of the backwards compatibility data of package-lock.json before a version of npm that does this by default is released.

What do you think?

[isaacs]

I love this idea, and it would be very easy to implement.

If we had a --lockfile-version option, we could also tell npm to create a "lockfileVersion":1 that only includes the npm v6 style dependencies section, which might also be nice for projects that might swap back and forth between v6 and v7.

So the possible values of the config would be 1, 2, or 3, with a default value of 2 in npm v7. And we could maybe say that even with this option, we'll never downgrade the lockfile if it's a version we know how to support. (Ie, if you have the default setting of 2, then a project with lockfileVersion:3 wouldn't be bumped down to 2.)

[G-Rath]

Would this allow us to also prevent v7 from being used on a project, by locking the lockfile version to 1? (or better yet, locking it to 1 so v7 would behave completely like v6 in terms of peerDependencies etc).

My work is not yet ready to switch to v7, but while we've requested devs stay on npm 6 for now, we've had a few instances of devs who've upgraded to npm 7 committing 2 lockfiles (which is hard to catch because most git repo services these days hide the lock file by default as a feature, meaning you have to explicitly remember to expand the diff and check the lock file version).

I'd love to be able to say "please always use the tree that'd be generated by npm v6" (which I assume can be done by locking the lock file to 1) so that devs who've upgraded wouldn't be able to generate a tree with npm v7s new logic.

[TooTallNate]

Was there any movement on this? I literally can't figure out how to generate a package-lock.json file with lockfileVersion: 3 🤔

[isaacs]

@G-Rath I think what you want is to put legacy-peer-deps = true in your project's .npmrc file. This will be ignored by npm v6, but will make npm v7 ignore any peer dependencies.

If you have a v6 lockfile, and are in legacy-peer-deps mode, npm v7 will follow the lockfile's instructions, but there is not (yet) any way to tell v7 to only save a v1 lockfile, so you'll get some source control churn if your team is mixed.

[isaacs]

@TooTallNate no motion yet, sorry. Like I said, it wouldn't be terribly hard to do, but it hasn't been prioritized and picked up by anyone to do the work.

The place to start poking would be in arborist's Shrinkwrap class. Basically, make the lockfileVersion a configurable option rather than hard-coding it to 2, and then make it know how to save just the pieces it needs to (v1 just the dependencies, v3 just the packages, v2 both).

Then the last mile to thread it through to the npm cli is adding a lockfile-version config entry in npm's config definitions file. Something like this:

// warning, not tested even a little!
define('lockfile-version', {
  default: 2,
  type: [1, 2, 3],
  description: `
    a descriptive description of what this thing does, in markdown
    with line breaks that will be sorted out later don't worry, but you
    do need to escape \`backticks\` because technically it's still js
  `,
  flatten,
})

Patch welcome!

[timtyrrell]

@G-Rath Can we not just pin the npm version to "npm": "^6.0.0" in the engines section of the package.json file and then set engine-strict to true in the .npmrc? (to enforce npm v6 without churn)

[valtlai]

This is implemented in npm v8.1.0. 🎉