Consider replacing core-js

[TrevorBurnham]

This project has a hard dependency on core-js, which is about 14MB of polyfills. It's unclear to me why that dependency is needed for something that runs in a Jest environment. As far as I can tell, it's indirectly used in the Babel configuration.

It's not entirely clear to me why there's a need for Babel at all here (I'd be curious to learn more!); but in the meantime, could core-js simply be moved to devDependencies in order to reduce the impact on consumers' node_modules?

Obligatory meme:

[Xunnamius]

Several things:

1. ±14MB for a non-production dependency in 2025 is a non-issue. And when I do use core-js to craft production dependencies that I'm sending to, say, the browser, any unused core-js polyfills (including ones that become no longer necessary due to browsers implementing them natively) are tree-shaken out by babel/swc (and/or my bundler of choice) so there is literally 0 additional cost when and where it matters.

2. NPM de-duplicates dependencies. core-js is one of the most popular libraries in existence in the JS ecosystem, so even if NTARH removed it from its dependencies, it'd very likely still be downloaded anyway since it'd still be somewhere else in the project's dependency tree.

3. NTARH, along with every other library I maintain, is required to work across all LTS (and current) versions of Node.js. LTS versions of Node.js have different features and different little idiosyncrasies and different levels of support for various JavaScript features. Add on top of that that LTS+current is a constantly moving target: the Node team routinely deprecates old LTS versions and adds new ones. I am just one humble engineer, I don't have time to track all of that. Babel + core-js smooths over these interoperability issues so I don't have to reason about them when writing code.

   Sometimes I even like using JS features that are stage 4 but not widely implemented (for instance, I was using Error.isError and RegExp.escape before they were cool), stage 3 features, and even trying out stage 2 features. Babel allows me to do this in a future-proof way while shipping code that works across LTS Node.js versions without any additional mental load and without causing any issues for package consumers. I also write my own babel plugins that serve my own purposes, such as enabling complex monorepo imports; thanks to babel, I had my own personal monorepo solution production-ready before tools like lerna, nx, or turborepo became popular. I'm still using my own solutions to this day.

4. I have ~20 years of JS experience and 10+ years of TypeScript experience, so I can confidently say: TypeScript is the golden child. TypeScript is life. Vanilla JavaScript is old news. Unfortunately, TypeScript is not natively understood by Node.js (though this appears to be changing) or browsers or most other runtimes. Babel takes my TypeScript and turns it into the exact type and kind of JavaScript I want it to. Emphasis on exact. The abstractions over JavaScript that TypeScript enables (especially around imports) leak exactly where I want them to leak, and don't leak exactly where I don't want them to, hence my code is all very easy to reason about even when I come back to it two years later.

5. Until very recently, ESM and CJS were incompatible: CJS code could not import ESM code without running into various annoyances (such as infecting the call stack with async code). These sorts of interop issues have roiled the JS/Node ecosystem for like a decade now. Using babel and core-js, I'm able to write a library once in TS in ESM syntax, transpile it down to JS in CJS syntax, and have that library work across all LTS versions of Node.js both ESM and CJS without running into things like the dual package hazard or degrading the DX for CJS users.

[TrevorBurnham]

Thanks for the thorough response! I have a better understanding of the purpose core-js serves now. I appreciate your work on this library, and I certainly don't want to complicate your workflow.

I will say that, in my Next.js application, this is the only dependency (dev or otherwise) that uses core-js. I think of core-js as a package that was essential a few years ago, but has faded in importance as IE11 has become a distant memory. It's particularly unusual to see it in a package that only targets LTS Node.js. But, if using those cutting-edge features you mentioned saves you time, great! I see the dependency's purpose now.

[Xunnamius]

Hmm. Good point about your Next project, though if you peek at their source code, the "14MB" of core-js and other polyfills are vendored—transpiled, minified, and then stuffed somewhere in their source tree—for various reasons above and beyond the existence of Internet Explorer.

So not seeing it as a dependency in npm list doesn't mean it's not there somewhere (or many somewheres) 😄. Next.js even includes its own entire copy of babel and react last I checked.

Still, I like your thinking. Maybe I can bake in some of the polyfills during the build step without pulling in core-js in it's entirety for some of my non-prod libs. I'll think more about it (and am open to suggestions).