> 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

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).

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.

That's actually pretty clever, in a "all hail the dark lord Cthulu" kind of way.

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.

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.

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.