3 ms·

Oh, so do I understand it right if you want your users to use specific pinned version for all of your dependencies? In that case why not pin to specific version

by 3np 3y ago

Oh, so do I understand it right if you want your users to use specific pinned version for all of your dependencies? In that case why not pin to specific versions (as opposed to semver ranges) in package.json, which would be respected identically by npm/yarn/pnpm and again remove the need for shrinkwrap?

davidmurdoch 3y ago
Yes. Because that doesn't pin dependencies of your dependencies (this is what "transitive dependencies" means).
- 3np 3y ago
  Would you like to do the same thing for Truffle/Ganache or are there non-political reasons why you don't find this approach suitable for either or neither?
  - davidmurdoch 3y ago
    I do this for the main `ganache` package, which is also mostly webpacked (only because of the install-time improvements it enables, and for easier browser usage), but not the other monorepo packages (they are all still pre-1.0.0 versions anyway, so I'm not as concerned with API or transitive dep stability). Truffle, which I don't work on myself very often, is more trusting of semver, and does use yarn for development. I in the past 've had to step away from a Thanksgiving dinner to do a hot fix release due to a transitive semver breakage, so I'm probably more sensitive to its problems than others. Yarn ignoring published lock files isn't totally crazy though. Yarn states that allowing automatic updates to transitive dependencies is better because users can respond to new security incidents faster than a chain of downstream package authors. An excellent point. My stance is that package authors generally introduce new breaking bugs/exploits much more often than they fix them; popular tools like Ganache are more likely to be the target of supply-chain attacks than non-financial tools. I'd honestly love to switch to, or support, a version of yarn, or pnpm, that allows package authors to prefer strict transitive dependencies, that can then be overruled by consumers of the package of they prefer a looser policy.

by 3np 3y ago

davidmurdoch 3y ago

Yes. Because that doesn't pin dependencies of your dependencies (this is what "transitive dependencies" means).

3np 3y ago
Would you like to do the same thing for Truffle/Ganache or are there non-political reasons why you don't find this approach suitable for either or neither?
- davidmurdoch 3y ago
  I do this for the main `ganache` package, which is also mostly webpacked (only because of the install-time improvements it enables, and for easier browser usage), but not the other monorepo packages (they are all still pre-1.0.0 versions anyway, so I'm not as concerned with API or transitive dep stability). Truffle, which I don't work on myself very often, is more trusting of semver, and does use yarn for development. I in the past 've had to step away from a Thanksgiving dinner to do a hot fix release due to a transitive semver breakage, so I'm probably more sensitive to its problems than others. Yarn ignoring published lock files isn't totally crazy though. Yarn states that allowing automatic updates to transitive dependencies is better because users can respond to new security incidents faster than a chain of downstream package authors. An excellent point. My stance is that package authors generally introduce new breaking bugs/exploits much more often than they fix them; popular tools like Ganache are more likely to be the target of supply-chain attacks than non-financial tools. I'd honestly love to switch to, or support, a version of yarn, or pnpm, that allows package authors to prefer strict transitive dependencies, that can then be overruled by consumers of the package of they prefer a looser policy.