Lock a sub-dependency version

[vjpr]

If a sub-dep releases a version which breaks a dep, this can break an entire app until a bug fix is issued. The workaround is to fork the deps, modify them, publish them, and change the require statments. This a painful, and bites me often.

A way to manually specify a sup-dep version would be very useful, and it is essentially what the shrinkwrap file does.

A command like pnpm lock foo.bar.baz@x.x.x, which would prevent a level 3 dep from updating.

This command would create a key in package.json like:

{
  "lockedDependencies": {
    "foo.bar.baz": "1.0.0",
  }
}

There would then be a warning each time a pnpm install is done to indicate that a dep is being locked.

So its basically like a manual shrinkwrap entry.

---

If this is too far out of scope for pnpm, it would be cool to have this functionality (manually specifying sub-dep) exposed in the pnpm api so that another tool could implement it.

[zkochan]

I like this idea a lot!

Why rewriting by dependency path? Why not just by spec?

{
  "lockedDependencies": {
    "foo@*": "1.0.0",
    "bar@2": "zkochan/bar"
  }
}

[vjpr]

The bug may only apply to a single dep. If you override by version, other deps would update.

The use case for using it would most usually be for a single dep breaking.

Therefore I think both is important.

note: cannot use dot as separator because it is valid in package name.

[andreineculau]

I believe what @vjpr is saying is that he would like to keep whatever works and just handle the errors with precision e.g. dep A has B@* as dependency, B has a major vsn release breaking integration with A, needs locking (although the lock doesn't need to be exact, but just another spec to point to the previous vsn in case it gets patch versions). Dep C has B@1.2.3 as dependency, needs no fixing.

[zkochan]

personaly I would always override all but we can support scoping. Something like

{
  "lockedDependencies": {
    "qar@1": {
      "foo@*": "1.0.0"
    },
    "bar@2": "zkochan/bar"
  }
}

looks pretty ugly, I don't know what the format should look like yet 😄

[vjpr]

@zkochan I like that already.

[zkochan]

what if I want to rewrite qar@1 as well?

[vjpr]

Hmm, I guess something like this but its a bit ugly - this is why flat might be nicer if we can figure out a way to delimit sub-deps...

"qar@1": {
  "root": "zkochan/qar",
  "bar@2": "zkochan/bar"
}

Some options for flat:

qar@1 > bar@2 <- This is how yarn prints its dep chains. Borrows familiar "direct descendant" css syntax.
qar@1..bar@2
qar@1|bar@2
qar@1$bar@2

[zkochan]

I'd suggest just using spaces. > means direct dependency. I think it'd be nicer to not limit ourselves with direct paths, so it'd be

{
  "lockedDependencies": {
    "qar@1 foo@1": "1.0.0",
    "bar@2": "zkochan/bar"
  }
}

[vjpr]

Yeh not needing to specify a direct dep chain would probably make life easier I think.

[zkochan]

I wonder if "locked" is the correct word here. Locked would probably be fine if we would only allow specifying a version that satisfies the original range. But we will allow anything, so maybe forcedDependencies or overridenDependencies.

Or even overridenSubDependencies

Or subDependencies?

[zkochan]

Had a conversation about this in a npm channel at discord:

Were you thinking about adding the feature of overriding subdepencies to npm? There is an issue at pnpm about this and I really like the idea: #651
In a nutshell, it would allow to force a different version in a subdependency?
If you'd be interested in this, we could try to use the same syntax/configuration(edited)

kat - Today at 7:40 PM
I wouldn't want to do this in package.json
I think this is the sort of thing that should only happen in lockfiles
zkochan - Today at 7:40 PM
but they are autogenerated, no?
kat - Today at 7:41 PM
It should also not allow users to violate semver requirements
Yes, but lockfiles are the ones that can do this kind of manipulation.

Fwiw, npm can already do this. Like, now.
zkochan - Today at 7:43 PM

It should also not allow users to violate semver requirements

so it would not allow to specify a version from a github branch, for instance?(edited)
kat - Today at 7:43 PM
You can easily write a third party tool that just edits your package lock if you're just using a slightly different version. The thing you'd want npm itself for is to reshape the tree if needed
That one's tricky: we have already decided and reasserted that we're never gonna allow replacing dependencies entirely like this, or having aliases.
The git version of the "same" package is still questionable
zkochan - Today at 7:46 PM
seems pretty useful though. If you fixed an issue but you have to wait a lot for it to get merged
like once I had to publish a whole set of packages with different names just because the maintainers were not responding
kat - Today at 7:47 PM
Right
zkochan - Today at 7:48 PM
and also with pnpm we have the issue that sometimes maintainers refuse to make changes "because it works with npm/Yarn"
kat - Today at 7:48 PM
So the only time I'd consider this is if the package has an identical name as well as a compatible version field
And imo the edit should be to the lockfile