5 ms·

This is what drives me insane about NPM. Libraries are useful, and even package splitting utils like underscore or babel make sense in some scenarios. But it on

by dexwiz 5y ago

This is what drives me insane about NPM. Libraries are useful, and even package splitting utils like underscore or babel make sense in some scenarios. But it only takes a few packages like these to explode the size of the dependency tree.

ratww 5y ago
Babel's splitting doesn't make much sense and is purely ideological. It's a monorepo, so split repos are not a development advantage. Plus, releases are often in sync. Plus, they recommend using presets rather than cherry-picking the specific plugins, making it kinda useless for end users. Plus, it's a CLI tool, so it's not really a necessary optimisation (and it would be a bad optimisation at that: having everything in a single package would make everything smaller and easier to compress).
- mintplant 5y ago
  For a long time, Babel plugins were entirely smoke-and-mirrors. If you looked under the hood at the source code of a "plugin" package, all it would contain was something like: require('babel').____secret____.enablePluginFoo = true; There was no actual plugin API, just selectively-enabled logic hardcoded into the main packages. The whole thing was fake-it-til-you-make-it.
  - akiselev 5y ago
    That's actually pretty clever, in a "all hail the dark lord Cthulu" kind of way.
  - acemarke 5y ago
    For built-in syntax parsing, yes - those official plugins just told the parser to enable those specific bits of syntax. Actual plugins for non-standard syntax were all real AST visitor-based modifications, though.
    - mintplant 5y ago
      I found this out some years ago while investigating how I might write my own Babel plugin for some non-standard syntax. At the time there were no such facilities available, only the hidden built-in parser flags.
gorjusborg 5y ago
> But it only takes a few packages like these to explode the size of the dependency tree. and create another future opportunity for a supply chain attack
bakuninsbart 5y ago
How long does it take to check the dependency tree of a package? If the package is trivial enough for it to not be worth to go through the dependency tree for 10-15 minutes, it wasn't worth it to include it in the first place. I'd rather have arbitrary depth of dependencies than some kind of governing system in NPM.

by dexwiz 5y ago

ratww 5y ago

Babel's splitting doesn't make much sense and is purely ideological. It's a monorepo, so split repos are not a development advantage. Plus, releases are often in sync. Plus, they recommend using presets rather than cherry-picking the specific plugins, making it kinda useless for end users. Plus, it's a CLI tool, so it's not really a necessary optimisation (and it would be a bad optimisation at that: having everything in a single package would make everything smaller and easier to compress).

mintplant 5y ago
For a long time, Babel plugins were entirely smoke-and-mirrors. If you looked under the hood at the source code of a "plugin" package, all it would contain was something like: require('babel').____secret____.enablePluginFoo = true; There was no actual plugin API, just selectively-enabled logic hardcoded into the main packages. The whole thing was fake-it-til-you-make-it.
- akiselev 5y ago
  That's actually pretty clever, in a "all hail the dark lord Cthulu" kind of way.
- acemarke 5y ago
  For built-in syntax parsing, yes - those official plugins just told the parser to enable those specific bits of syntax. Actual plugins for non-standard syntax were all real AST visitor-based modifications, though.
  - mintplant 5y ago
    I found this out some years ago while investigating how I might write my own Babel plugin for some non-standard syntax. At the time there were no such facilities available, only the hidden built-in parser flags.

gorjusborg 5y ago

> But it only takes a few packages like these to explode the size of the dependency tree. and create another future opportunity for a supply chain attack

bakuninsbart 5y ago

How long does it take to check the dependency tree of a package? If the package is trivial enough for it to not be worth to go through the dependency tree for 10-15 minutes, it wasn't worth it to include it in the first place. I'd rather have arbitrary depth of dependencies than some kind of governing system in NPM.