4

I have npm version 6 installed on my machine. I have the following content in package-lock.json:

{
  "name": "Project",
  "version": "0.0.0",
  "lockfileVersion": 1,
  "requires": true,
  "dependencies": {
    "package1": {
      "version": "0.1.2"
    },
    "package2": {
      "version": "0.2.2"
    }
  }
}

Whenever I am running npm install it's updating my package-lock.json and new contact is like:

{
  "name": "Project",
  "version": "0.0.0",
  "lockfileVersion": 1,
  "requires": true,
  "dependencies": {
    "package1": {
      "version": "^0.1.2"
    },
    "package2": {
      "version": "~0.2.2"
    }
  }
}

I am expecting to not add ~ tild or cap ^ into the version of package-lock. I am not even adding or removing any package before npm install. Lock file is very big so it's hard to maintain changes manually.

What is the problem? How should I install new packages without affecting old versions?

Manwal
  • 23,450
  • 12
  • 63
  • 93

1 Answers1

0

As per my understanding and whatever I searched on this,I can able to say that,this(package-lock.json) behavior is refactor to make traceability of dependencies easier, even if getting some large lock file diffs in the meantime is not ideal. package-lock.json should be the tool and mechanism what is responsible to keep everything consistent, so the trust in it is unavoidable and necessary.

Documentation

package-lock.json describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.

For example, package.json is:

...
  "glamor": "^2.10.00"
...

In package-lock, there are links to specific versions, for example, https://registry.npmjs.org/glamor /-/glamor-2.20.40.tgz The change only touched the format of the require description. It was:

"requires": {
  "glamor": "2.20.40"
}
Became:

"requires": {
  "glamor": "^2.0.0"
}

Semver was not broken (2.20.40 is still matching to ^2.0.0), and the links remained in place When the package version is updated, the package will still be taken from the link file (there is an old version of the package) To update the link in the lock file, you must either change package.json or make npm update. For more reference npm issues

More explanation on this:

Let's say that you use pinned versions of dependencies 'aaa', 'bbb' and 'ccc'. Let's say they each depend on 'zzz' like so:

aaa depends on zzz@^1.0.0 bbb depends on zzz@^1.1.0 ccc depends on zzz@^1.0.1

i.e. all three of them depend on a range of zzz, and not an exact version.

And let's say that the latest version of zzz is 1.5.0.

Both before and after this change, it's pretty obvious that the resolved version of zzz should be 1.5.0, so the only difference is how the package-lock.json is structured and documents this sub-dependency.

Before, the lock file would show that all three of them depend on zzz@1.5.0, and the resolved version of z is 1.5.0.

Now, it documents the actual "original" dependency versions (e.g. ^1.0.0, ^1.1.0, etc) for each dependency, but still shows the resolved version of z as 1.5.0.

Then consider what happens when zzz@1.5.1 is released:

Before, the lock file would need to update from z@1.5.0 to z@1.5.1 in all four places.

Now, the lock file only needs to update the resolved version of z to 1.5.1 while the dependencies can keep the ^1.0.0, ^1.1.0, and ^1.0.1 because they haven't changed.

As I mentioned previously in the thread, you still get the exact same node_modules in both cases. The advantages of the new approach are:

You get to see what the dependencies actually require (e.g. a range, and not an exact version). before, you could not tell if aaa actually required exactly zzz@1.5.0 or that it was instead zzz@^1.0.0.

Instead of four lines changing in the lock file, you get only one. It's less churn, and it's more clear what's happened.

As an aside, yarn uses a similar concept with yarn.lock. e.g. here's an example where @sindresorhus/is is pinned, but it's sub-dependency symbol-observable is not:

"@sindresorhus/is@0.10.0":
  version "0.10.0"
  resolved "https://registry.yarnpkg.com/@sindresorhus/is/-/is-0.10.0.tgz#f42dd6a9d12cd79fa6f53b27cf5bea3a30d2cafa"
  dependencies:
    symbol-observable "^1.2.0"
Avinash Singh
  • 4,970
  • 8
  • 20
  • 35