3 ms·

I didn't know that about yarn transitives, do you have a link explaining more about the problem? I assumed a yarn.lock would.. lock, interesting to know more.

leipert 5y ago
I assume the author is talking about the following problem: I build library X and ship it with a lockfile to lock all transitive dependencies. User installs library X, even though I ship a lock file, it isn’t respected. (I assume this makes Resolution way to complex) If you ship a library where everything is locked, one should consider vendoring their dependencies. I think this is what npm does itself. (Or used to do). Or consider reducing your dependencies.
- eyelidlessness 5y ago
  > I assume this makes Resolution way to complex I can’t speak to Yarn’s motivation, but I suspect for most Yarn users it’s not dissimilar to my own: pinning exact versions of transitive dependencies can be a big source of “audit fatigue” with NPM. It’s fine that authors wish to limit the surface area of version ranges they support, but for downstream users this can often mean being essentially held hostage with potential exposure to vulnerabilities and no reasonable alternative. Yarn should, like NPM, default to honoring all pinned dependencies. Both now have facilities to override those defaults (resolutions/overrides respectively), which is important. But there should also be a more gentle middle ground of “yes I want to assume this library meant to use semver, I understand I’m slightly relaxing the contract in the lockfile” in the form of a CLI flag… rather than manually writing potentially hundreds of lines of JSON. > Or consider reducing your dependencies. I mean, that sounds nice in theory. But the whole number of dependencies thing is a systemic design problem more than anything. No one is installing 1000s of dependencies. They’re installing ~5-10 and getting 1000s.
  - davidmurdoch 5y ago
    > Yarn should, like NPM, default to honoring all pinned dependencies. Both now have facilities to override those defaults (resolutions/overrides respectively), which is important. But there should also be a more gentle middle ground of “yes I want to assume this library meant to use semver, I understand I’m slightly relaxing the contract in the lockfile” in the form of a CLI flag… rather than manually writing potentially hundreds of lines of JSON. Yes, this! I want this, and for all nose package managers to share a lock file format.
davidmurdoch 5y ago
If a dependency includes it's own yarn.lock yarn will ignore it. It DOES respect the local lock file though, so it's not all bad.
- nhoughto 5y ago
  ah ok so as a library author you can't actually enforce _your_ assumptions about transitives, bc user of the library local lock file overrides but as a library user with a local lock file that I craft and care about it is effective. That is a relief.
  - davidmurdoch 5y ago
    Yes. It's not a relief for everyone, especially library authors, as bugs can happen only on your particular set of transitive dependencies. What a fun time those days were. Anyway, semver makes me sad sometimes. Haha

leipert 5y ago

I assume the author is talking about the following problem: I build library X and ship it with a lockfile to lock all transitive dependencies. User installs library X, even though I ship a lock file, it isn’t respected. (I assume this makes Resolution way to complex) If you ship a library where everything is locked, one should consider vendoring their dependencies. I think this is what npm does itself. (Or used to do). Or consider reducing your dependencies.

eyelidlessness 5y ago
> I assume this makes Resolution way to complex I can’t speak to Yarn’s motivation, but I suspect for most Yarn users it’s not dissimilar to my own: pinning exact versions of transitive dependencies can be a big source of “audit fatigue” with NPM. It’s fine that authors wish to limit the surface area of version ranges they support, but for downstream users this can often mean being essentially held hostage with potential exposure to vulnerabilities and no reasonable alternative. Yarn should, like NPM, default to honoring all pinned dependencies. Both now have facilities to override those defaults (resolutions/overrides respectively), which is important. But there should also be a more gentle middle ground of “yes I want to assume this library meant to use semver, I understand I’m slightly relaxing the contract in the lockfile” in the form of a CLI flag… rather than manually writing potentially hundreds of lines of JSON. > Or consider reducing your dependencies. I mean, that sounds nice in theory. But the whole number of dependencies thing is a systemic design problem more than anything. No one is installing 1000s of dependencies. They’re installing ~5-10 and getting 1000s.
- davidmurdoch 5y ago
  > Yarn should, like NPM, default to honoring all pinned dependencies. Both now have facilities to override those defaults (resolutions/overrides respectively), which is important. But there should also be a more gentle middle ground of “yes I want to assume this library meant to use semver, I understand I’m slightly relaxing the contract in the lockfile” in the form of a CLI flag… rather than manually writing potentially hundreds of lines of JSON. Yes, this! I want this, and for all nose package managers to share a lock file format.

davidmurdoch 5y ago

If a dependency includes it's own yarn.lock yarn will ignore it. It DOES respect the local lock file though, so it's not all bad.

nhoughto 5y ago
ah ok so as a library author you can't actually enforce _your_ assumptions about transitives, bc user of the library local lock file overrides but as a library user with a local lock file that I craft and care about it is effective. That is a relief.
- davidmurdoch 5y ago
  Yes. It's not a relief for everyone, especially library authors, as bugs can happen only on your particular set of transitive dependencies. What a fun time those days were. Anyway, semver makes me sad sometimes. Haha