CJS support #3103
Replies: 1 comment 10 replies
-
|
First things first, thank you for opening a separate discussion to keep the context clear and minimal. Just to be transparent about this topic: |
Beta Was this translation helpful? Give feedback.
-
|
So, our main concerns here seem to be:
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 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. |
Beta Was this translation helpful? Give feedback.
-
FYI there was #1287 that experimented with this approche. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
There are certain tradeofs to everything.
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions