Very large bundle size

[achingbrain]

When using the in-memory rate limiter in browsers it results in a bundle addition of 42KB:

If I pull just the depended on files out of this module it's more like 4KB:

I think this is because this module is CJS and exports all the various implementations in one blob which makes tree shaking impossible.

Could this module be updated to be ESM with only named exports?

[LGmatrix13]

Not sure how much of a drop-in replacement this would be, but bun has become a popular bundler lately since it can export a package to all the different js extensions, including ESM.

https://bun.sh/docs/bundler#content-types

[animir]

@achingbrain The question about ESM is interesting.
I don't have much experience with tree-shaking optimizations. Different projects use different approaches. Can we keep both CJS and ESM without breaking dependent projects?
Do you have any suggestions on changing it with or without breaking changes?

[animir]

@LGmatrix13 Thanks, it looks promising.
I still get my head around the idea of having ESM module exports.
Not sure, what's the best practice here.
Should it be provided with both options CJS and ESM? Or just ESM and deprecate using CJS? If both how it is published to npm? Maybe I asked you too many questions already :-) Sorry, just not sure how to proceed.

[achingbrain]

Can we keep both CJS and ESM without breaking dependent projects?

There are a few caveats around shipping both - the same authored class imported by a CJS file and a ESM file is treated as a separate class by the js runtime (since the classes were loaded from different locations) so were you to pass the instance between them instanceof won't work as expected, and like this you can end up including both versions in your bundle by accident.

Tools like rollup will create CJS/ESM versions and you can let the runtime select them with an "exports" entry in the project's package.json:

{
  "exports": {
    ".": {
      "types": "./path/to/index.d.ts",
      "require": "./path/to/index.cjs.js",
      "import": "./path/to/index.esm.js"
    }
  }
}

From my experience the short term pain of going ESM-only is preferable to the long-term pain of supporting both CJS and ESM exports.

[animir]

@achingbrain Thank you for your valuable input.

I think, it is better to go clean ESM since Node.js natively supports it.
I've prepared a PR with refactoring. Could you double check this index.js https://github.com/animir/node-rate-limiter-flexible/pull/250/files#diff-e727e4bdf3657fd1d798edcd6b099d6e092f8573cba266154583a746bba0f346 is what allows to make optimal tree-shaking?

[mroderick]

This issue is really a shortcoming of the bundler/treeshaker used by OP and not of rate-limiter-simple.

Since OP is using ESM, they can deep import files from the package, circumventing to the root file and helping their treeshaker out.

import RateLimiterMemory from "rate-limiter-flexible/lib/RateLimiterMemory.js";

console.log(typeof RateLimiterMemory);
// => function

That means that we don't need to convert this codebase to ESM just yet or in a hurry, but can take our time and do it without introducing new problems for users.

[djMax]

the words "clean" and "ESM" are antonyms. Please don't convert this repo.

[animir]

@djMax Could you tell more about your concern on ESM?

[Systerr]

Converting to ESM is a really good idea. Node.js has natively supported it for a long time, and browsers also support it. For CJS (CommonJS) node executions, developers can use "async import()" (dynamic import)