[RRFC] Support combining workspace package-lock files into a central package-lock when adopting workspaces

[thernstig]

Motivation ("The Why")

We are moving from a non-workspace repository to using the workspaces feature. Previously we had two workspaces like workspace-a/package-lock.json and workspace-b/package-lock.json. When we add these as:

{
  "name": "my-workspaces-powered-project",
  "workspaces": [
    "workspace-a",
    "workspace-b"
  ]
}

we get a package-lock.json in the root, which is the only one that should be kept (removing the ones in the workspace folders).

The problem we have is that this does not pin the exact versions we have in our previous package-lock.json files. For example

    "node_modules/engine.io-parser": {
      "version": "4.0.2",

gets changed to

    "node_modules/engine.io-parser": {
      "version": "4.0.3",

This is not wanted, due to that we require the exact version pinning due to how our internal systems has a process to update dependencies' versions. Something that we cannot do as part of this upgrade. It would be far too extensive.

Example

• It would let users move to workspaces without the risk of non-wanted upgrades as part of the process

How

Current Behaviour

Even if we have pinned packages in package.json, the subdependencies of packages might use ^ or ~ specifiers, which makes their subdependencies get new versions in the new top-level package-lock.json file.

Desired Behaviour

Add a flag to the npm cli like to allow for no version upgrades at all from how they looked in the previous workspace's package-lock.json file.

References

• Related/Reference to https://github.com/npm/cli/issues/4350

[ruyadorno]

hi @thernstig I would love to hear if you can manage to do that (achieve that desired behavior) by using npm update --save from the root folder.

npm update --save has the logic to avoid upgrading pinned dependencies so maybe that's going to be everything you need in this particular case. Please let me know if you can give it a try! Thanks!

[thernstig]

@ruyadorno unfortunately that did not work. Multiple package's versions were updated, e.g. the PATCH version of semver. Of course, if npm update --save could be "fixed" to handle this, that sounds like a good way forward.

[thernstig]

@ruyadorno do you consider it a bug that npm update --save did not work as you expected?