CJS/ESM module exports

[matteosacchetto]

I discovered this library quite recently, and I find it very interesting, since it provides a lot of useful functions while being rather lightweight. But I have a question/idea for you

What about providing two different export, one for CJS modules and one for ESM modules?

So, I am asking this more from a performance standpoint, and the reason is the following: by providing an ESM module export it could allow bundlers like Rollup, which take advantage of ES6 named exports, to threeshake the code and import only the functions which are actually used. It could provide smaller builds for those using Rollup or tools based on that, like Vite.

I personally believe that at that point it would get even better than it already is, allowing people to take advantage of this library while keeping the builds smaller.

I did a small test, using Vue with Vite and I added a small piece of code in the App.vue component:

import { first } from "radash";

const arr = ['a', '2', 't']
const first_el = first(arr);

console.log(first_el);

I then tried cloning the repo and updating the tsconfig.json file to build for esnext, and copied the build directory within the src directory and called it radash. To use this build the only difference with respect to above was the import which became:

import { first } from "./radash";

In this test, the difference in build size of the Vue app between the two configurations was of about 20KiB

What do you think about this?

Thank you for your time and keep up the good work!! 💪🏼
Matteo

[sodiray]

Thanks for the kind words @matteosacchetto ! I'm stoked you found radash and your a fan 🍻

I like what you're suggesting! I know there are some libraries out there that used to be cjs and made the switch at a major version bump. Sometimes I want to use them but I can't (or I have to install an older version). I've hit this page A LOT.

Any ideas on how to make a better experience if we do provide esm? Like, maybe publishing radash (cjs) and radash-next (esm) to npm? Maybe thats not a great solution either... 🤔

I should tell you, I've never even used an esm library. I should really do a deep dive myself. Feel free to correct me or teach me on the subject if I'm way off base.

[matteosacchetto]

Hi @rayepps, yeah, I totally understand the frustration of having to deal with library which are now only ESM and a codebase which is still using CJS code, it happened to me a lot, until I decided to go for implementing new projects using the ESM module syntax, and it has been great so far. One cool this is that in node you can import easily CJS modules in ESM codebase, while the other way around is kind of a pain to deal with.

Anyway, I believe that in order to do so you can follow two alternative paths

Solution 1: create two different packages, one for the CJS export and one for the ESM export
Pros:

• This somewhat isolates the two version and in order to use one or the other the user has to decide which one to install
• The size of the package you download from NMP is the same as it is currently
  Cons:
• Managing two different packages may be more difficult

Solution 2: define two entry points, one for CJS' require, and one for ESM export
Pros:

• Probably easier to deal manage one package with two exports
• This is more "transparent" to the user, which just installs radash and does not have to remember the correct name for the relative version
  Cons:
• The size of the package you download from NMP is practically doubled
• Issues may arise if both require and import of the package are used within the same project (this should be like an edge case though)

Regarding the second solution I leave here some references on how to do it:

• NodeJS doc on the topic
• Stackoverflow resource on how to build mutliple targets with typescript
  • Regarding this last resource I have some possible suggestions which may help to make the process more transparent to you:
    • You could define a basic tsconfig.base.json file with common configuration
    • Then you can define a tsconfig.json which extends `tsconfig.base.json defines compiler options for cjs (the ones you use currently)
    • Then you can define a tsconfig.esm.json which extends `tsconfig.base.json defines compiler options for esm modules
    • This way the tsconfing.json should have the same config as you currently have, and you do not have to change anything else (so if you use any tool relying on a file named tsconfig.json it will still work hopefully) for CJS build, then you can add the npm scripts related to the esm build specifying the tsconfig.esm.json config

Unfortunately I also have no experience in writing a library which provides both CJS and ESM exports, but I do know that threeshaking with ESM modules is something which you get out of the box, and especially for people developing frontend having smaller builds would be great

No hurry on this, is still just an idea, would be awesome to see what others may think on this

Thank again for you time and have a nice day! 😃

[sodiray]

Thanks for the breakdown and doing some experimenting! Would you be willing to make a PR with the changes you made experimenting with solution 2?

[matteosacchetto]

Sure thing! The code I have is kind of a mess right now... So, I will try to organize it a little bit and will then do a PR. In the meantime I had an idea about handling the build step. What would you think about using rollup? I know i know, It may seem to complicate things, but from my experience, when I was dealing with TS and ES6 code Rollup helped a ton!!

If you are interested in knowing something about Rollup with TS, i link here the repo which I use as baseline for most of my projects. It is designed more towards node apps rather than libraries, but it shows you something about how I used rollup 😃

Maybe it is something you could find useful

Cheers

[dolsem]

@rayepps I came across this library template earlier today and used it to publish an NPM package, it's pretty simple and works well - https://github.com/gjuchault/typescript-library-starter

It creates 2 entrypoints as part of the NPM package, so that node or your bundler choose the appropriate one depending on your environment.

[matteosacchetto]

Ok, so, using rollup I was successful! @rayepps, just let me know if you are familiar with this bundler or not and if you are open to a solution which uses it

The output dir structure I obtained is the following

dist
├── cjs
│   ├── index.js // exported as CJS export
│   └── index.js.map
├── esm
│   ├── index.js // exported as ESM export
│   └── index.js.map
└── index.d.ts // exported as type export

Based on your input on this I will then proceed with a pull request or find other solutions.

@dolsem, sorry if I ended up not using your solution, but I found it easier to do it with rollup, which I am more familiar with

[matteosacchetto]

Just to let you know, I addressed this with pull request #81
This should solve also issue #79

Cheers,
Matteo