CJS support

[notaphplover]

While discussing #3087 it came to my attention CJS might stop being supported on the next major release.

Is that so? Are you open to discuss this topic?

My cup of tea would be continue supporting CJS, and since other users (even faker contributors) share the same concerns, I though it might be worth discussing this topic.

[xDivisionByZerox]

First things first, thank you for opening a separate discussion to keep the context clear and minimal.

---

Just to be transparent about this topic:
While not specifically mentioned in any issue/PR or documentation, it is part of the description for the milestone for v10.

[notaphplover]

So, our main concerns here seem to be:

1. The additional complexity as a result for supporting both CJS and ESM modules.
2. Package sizes.

Is that so?

Regarding the additional complexity of supporting both ESM and CJS modules, it's a trade of. I agree removing CJS support would led to a much simpler library. But CJS support is a feature demanded in your userbase. If backend projects rely on faker to generate fake data, removing CJS support is a problem. It has already happened in the past. Consider got weekly downloads: only around 15% of then target got@12 or greater. Can you wonder why? Simple: got@12 droped CJS support and it's supposed to be a nodeJS library. That also explains why got@11 is, by far, the most downloaded version set. I think this is an example of what removing CJS support means in the backend ecosystem. In a perfect world, we all would use ESM, of course. But I'm afraid it's not the case.

Regarding package size, is that important?

faker is mostly used as dev dependency. Even as non dev dependency, if package size is a concern, doesn't any sort of tree shaking approach simply deal with this problem? I mean, If I use faker as a non dev dependency, I'd be puting my faith in a bundler good enough to know I'm targeting ESM so CJS modules from faker should not be transpiled nor bundled since faker is already providing ESM ones.

For the sake of a constructive feedback, we can simply ignore what I said and focus on the package size. Even in this case, I wonder if droping CJS support is the solution to your problem. Maybe having a big package size is a problem that demands a solution, but it doesn't necessarily mean that dropping CJS support is the right approach. I do like @xDivisionByZerox approach of providing locale packages (which maybe would be installed as peer dependecies?), but my 5 cents to this discussion would be: why are we coding data as code? Maybe we are considering an unnecessary duplication of code because, in the end, translations are data rather than code?

An npm package has modules, but an npm package doesn't necessarily include only modules. You can include any file as well. You can include json, as an example, and it's perfectly fine to have a translation package with json translations and import them / require them. It's an alterative approach that would deduplicate translations.

[xDivisionByZerox]

[...] why are we coding data as code? Maybe we are considering an unnecessary duplication of code because, in the end, translations are data rather than code?

An npm package has modules, but an npm package doesn't necessarily include only modules. You can include any file as well. You can include json, as an example, and it's perfectly fine to have a translation package with json translations and import them / require them. It's an alterative approach that would deduplicate translations.

FYI there was #1287 that experimented with this approche.

[Shinigami92]

As @xDivisionByZerox posted, I for myself already suggested this years ago! And for me we now running in circles. I'm so tired and sick of cjs that I think I would leave Faker behind me if we don't drop cjs support in v10.
If some of the community still need cjs for legacy project reasons, they are totally safe to pin v8 or v9 and stick to it. Faker does not even have direct dependencies and so they won't introduce security risks as far as I can tell.
I have zero problems with leaving the cjs community behind and move on, because we have this situation for years now in the ecosystem and if big libraries with millions of downloads a week don't enforce and move on, this situation will stay for years.

[ST-DDT]

There are certain tradeofs to everything.

• if we switch to json data:
  • our bundle size might be smaller
  • there is some additional complexity related to type checking of the json data
  • the theoretical min bundle size of our users will be bigger (because data objects aren't tree-shaken). See also nano bound standalone module functions Proposal: Design for standalone module functions #2667 (this depends a bit on which files are jsonified)
• as for cjs:
  • I'm not against retaining support for it, but it must be worth it
  • dropping support for it would reduce our build process complexity by a lot, we could potentially switch back to plain tsc. We could then invest that complexity into new features such as nano bound module functions.
  • we are currently experiencing build issues related to cjs and moduleResolution, so it causes perceived pain. If you/the community could review and test the related PRs, that would restore some confidence in them. [9.0.0] Types are not properly emitted #3087

[notaphplover]

Thank you so much for all your feedback. It's really appreciated.

If json files cannot be tree shaked, I would avoid then in favor of module duplication.

I've had a look at #2667, it looks great, it was quite instructive tbh.

Regarding the use of tsc, may I know what's blocking you from using it? I wasn't expecting cjs support to be part of the problem, I was expecting whatever tsc based config which works on ESM can simply be replicated on CJS unless some few exceptions.