[no_wizard]

Marvin is doing wonderful work in the JS ecosystem around performance. It has been largely focused on tools and node, however, he did have an interesting set of things to say about how they optimized performance in Preact as well on his website that was really interesting too.

One thing I've noticed is the rampant duplication of polyfills and babel helpers. To the point that I now have overrides setup via pnpm and I re-write many imports of polyfills to point at my own shims, which simply re-export existing functionality native to the language, most of the time.

For smaller utility packages, I often simply clone the repo and copy things over that we need, or copy the src right out of the node_modules folder if possible, then I strip away all the superfluous imports (and often convert from commonjs to ESM if needed)

Saves so much headache, its better for users, smaller builds etc.

[Dextro]

That sounds awesome. I've dabled with something like that but only for lodash (makings sure all different flavours get aliased to a single thing) but I never went too far with all the other stuff.

You wouldn't happen to have an example of what you're doing laying around would you? I'd be genuinely curious to try stuff like that out.

[mhagemeister]

Author here.

Thanks for the kind words! It's feedback like this that encourages me to keep writing about it.

I share your experiences regarding babel helpers and haven't found a good solution myself. Similar to you, I often patch unnecessary stuff out via patch-package, but that approach doesn't scale well.

[no_wizard]

I use path resolution, it tends to scale better (not great but better) for Babel helpers because ‘Babel-runtime’ can 100% be re-mapped to ‘@babel/runtime’. Same with corejs 2 -> 3, they just need path mapping.

Patching packages is definitely something I still have to do to strip polyfills and convert CJS to ESM if I can’t simply re-compile source