3 ms·

This is a very well known trick that we don't talk about much in public, but this is how most people with hundreds of repos on NPM get to this number. One very

by ratww 5y ago

This is a very well known trick that we don't talk about much in public, but this is how most people with hundreds of repos on NPM get to this number. One very popular terminal progress bar spinner has over 30 dependencies. One with the list of colors, another to display colors, another to clean the line, another to check if emojis are supported, another one with a list of emojis... plus a whole lot of wheel reinvention. It was visible that most code in the sub-packages were just functions copied almost verbatim from StackOverflow. It was also extremely limited when I tried to use it, and had quite a few bugs (it only really worked well on Macs at the time), despite the extremely large number of dependencies. Reimplementing took about 20 lines.

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.
hulitu 5y ago
Wow, you just gave me a great idea for libc. Why not split it in libprintf, libscanf, libexit, libitoa, libstrbcpy etc. ? I'm sure the world will be better after this.

by ratww 5y ago

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.

hulitu 5y ago

Wow, you just gave me a great idea for libc. Why not split it in libprintf, libscanf, libexit, libitoa, libstrbcpy etc. ? I'm sure the world will be better after this.