4 ms·

> If you are bundling dependencies, you are not allowing people to get updates to your sub-dependencies with semver! That's a reason for bundling.

_ZeD_ 4y ago
if you want to work with a vendored copy of a dependency, do it clearly; copy the sources in src and remove the dependency from the package.json
- laundermaf 4y ago
  For what? If you want to alter it, yes, otherwise package.json already has `bundledDependencies` to achieve the same without cluttering your repository.
creatonez 4y ago
So... set ourselves up for another Log4j situation where a vulnerability is found in a sub-sub-sub dependency of some dependency you didn't even know you were using, such that only good way of fixing it is to manually scrub the code from `.jar`s?
- davidmurdoch 4y ago
  Or wait a few days for a patch to be released.
  - creatonez 4y ago
    Wait a few days for what, exactly? For your sub-sub-sub dependency to patch it, then for your sub-sub dependency to notice this and update the version, then for your sub-dependency to notice it to update it, then for your dependency to finally notice and update it? The solution that npm presents solves this problem without this insanity -- you can just create a `npm-shrinkwrap.json` file to manually update sub-dependencies. If one of your dependencies used bundling, this solution becomes impossible.
    - moltar 4y ago
      In NPM 8 you can override sub deps quite effectively, even using references. Another option is package-patch. Very light, elegant and yet robust solution for fixing anything in any package you depend on yourself without waiting for maintainer to fix it.
laundermaf 4y ago
You missed the point of Node’s dependency resolution. If you want to lock the dependencies, just use a lockfile in your app, you don't need to ship the same code 10 times because your dependencies already decided to bundle their sub-dependencies.
- davidmurdoch 4y ago
  No, I understand, I just don't trust semver. Node package managers don't agree on lock file formats, and yarn doesn't read dependency lock files at all.

_ZeD_ 4y ago

if you want to work with a vendored copy of a dependency, do it clearly; copy the sources in src and remove the dependency from the package.json

laundermaf 4y ago
For what? If you want to alter it, yes, otherwise package.json already has `bundledDependencies` to achieve the same without cluttering your repository.

creatonez 4y ago

So... set ourselves up for another Log4j situation where a vulnerability is found in a sub-sub-sub dependency of some dependency you didn't even know you were using, such that only good way of fixing it is to manually scrub the code from `.jar`s?

davidmurdoch 4y ago
Or wait a few days for a patch to be released.
- creatonez 4y ago
  Wait a few days for what, exactly? For your sub-sub-sub dependency to patch it, then for your sub-sub dependency to notice this and update the version, then for your sub-dependency to notice it to update it, then for your dependency to finally notice and update it? The solution that npm presents solves this problem without this insanity -- you can just create a `npm-shrinkwrap.json` file to manually update sub-dependencies. If one of your dependencies used bundling, this solution becomes impossible.
  - moltar 4y ago
    In NPM 8 you can override sub deps quite effectively, even using references. Another option is package-patch. Very light, elegant and yet robust solution for fixing anything in any package you depend on yourself without waiting for maintainer to fix it.

laundermaf 4y ago

You missed the point of Node’s dependency resolution. If you want to lock the dependencies, just use a lockfile in your app, you don't need to ship the same code 10 times because your dependencies already decided to bundle their sub-dependencies.

davidmurdoch 4y ago
No, I understand, I just don't trust semver. Node package managers don't agree on lock file formats, and yarn doesn't read dependency lock files at all.