Replace CommonJS-only dependencies with inline ESM code

[andreialecu]

Problem

When using mathjs in an Angular project (and likely other modern ESM-first bundlers), the following warnings are emitted during the build:

▲ [WARNING] Module 'seedrandom' used by 'node_modules/mathjs/lib/esm/function/probability/util/seededRNG.js' is not ESM

▲ [WARNING] Module 'escape-latex' used by 'node_modules/mathjs/lib/esm/utils/latex.js' is not ESM

▲ [WARNING] Module 'javascript-natural-sort' used by 'node_modules/mathjs/lib/esm/function/relational/compareNatural.js' is not ESM

▲ [WARNING] Module 'tiny-emitter' used by 'node_modules/mathjs/lib/esm/utils/emitter.js' is not ESM

CommonJS or AMD dependencies can cause optimization bailouts.
For more information see: https://angular.dev/tools/cli/build#configuring-commonjs-dependencies

Proposal

All four of these dependencies are tiny libraries that haven't been updated in 7+ years:

Package	Last publish	Size
seedrandom	7 years ago	small
escape-latex	7 years ago	small
javascript-natural-sort	9 years ago	small
tiny-emitter	7 years ago	small

Since they are unmaintained and unlikely to ever ship ESM builds, I'd suggest inlining their code directly into mathjs as proper ESM modules. This would:

1. Eliminate the CommonJS warnings for Angular/esbuild/Vite users
2. Allow tree-shaking to work properly on this code
3. Remove external dependencies that are effectively abandoned

I'll follow up with PRs to inline each of these.

[andreialecu]

PRs for all four dependencies:

Package	PR
seedrandom	#3650
escape-latex	#3651
javascript-natural-sort	#3652
tiny-emitter	#3653

Each PR inlines the dependency as a clean ESM module with comprehensive tests ported from the upstream repos. The javascript-natural-sort replacement also includes a ~20% performance improvement over the original.

[josdejong]

Thanks for working on a solution for this Andrei! However, I'm not sure if we should inline these dependencies. It makes the codebase of mathjs larger. How about creating a fork of these projects, converting them to ESM, and then publish them on npm (that could be useful for many more people)? Or find a similar alternative that is maintained and has ESM. On the other hand: having less dependencies also reduces risk. I have to give this some thought. What do you think?

Related: #1841, #1928

[andreialecu]

Personally, I would prefer if mathjs took the approach of having fewer dependencies, for security.

Supply chain attacks are becoming increasingly trivial, especially now that LLMs make it easy to craft convincing malicious packages or hijack unmaintained ones.

These dependencies are tiny, take a look at the PRs. Inlining them would have minimal impact on the codebase size, while definitely decreasing the overall bundle size and increasing performance.

They also include full test suites, and I don't think anyone will ever need to touch them since they haven't been updated upstream in 7-12 years anyway.

Fewer dependencies = smaller attack surface + smaller bundles. Seems like a win-win to me.

Here's something relevant and recent: https://x.com/karpathy/status/2036487306585268612

Classical software engineering would have you believe that dependencies are good (we're building pyramids from bricks), but imo this has to be re-evaluated, and it's why I've been so growingly averse to them, preferring to use LLMs to "yoink" functionality when it's simple enough and possible.

[andreialecu]

Relevant, and just in:

https://www.aikido.dev/blog/axios-npm-compromised-maintainer-hijacked-rat