distribute as native ES module

[elf-pavlik]

All major browsers support ES modules, I think having option to import cuid directly in a browser will come handy. Possibly esm could provide an easy way to expose it to CJS ecosystem as well.

[ericelliott]

Open to a PR

[robertdmunn]

I built an ES6 distribution yesterday. Since the import statements can't be conditional, I made a separate set of files for the distribution - index.es6.js, etc. I'll make a pull request if that seems OK, or you can suggest an alternative. I didn't write add tests for it, but I have confirmed in a separate app that it works.

You can see my changes here:

https://github.com/robertdmunn/cuid/tree/es-module

[elf-pavlik]

It looks like your fork introduces some code duplication, I'll look into https://www.npmjs.com/package/esm based approach which doesn't duplicate any code.

[ericelliott]

This is honestly not a high priority for me. I'm using babel and esm in my projects, which makes this issue pretty much invisible to me.

What problem are we trying to solve?

[elf-pavlik]

All major browsers support ES modules, I think having option to import cuid directly in a browser will come handy.

If everything here use ES modules and esm makes it available for nodejs, it can also work in a browser without requiring any build step.

[robertdmunn]

Yep, I made an edit to my post that didn't stick for some reason. I thought about a build-based approach using grunt or similar to create builds for different module loaders. The actual loading code is pretty minimal.

It looks like your fork introduces some code duplication, I'll look into https://www.npmjs.com/package/esm based approach which doesn't duplicate any code.

[robertdmunn]

Using ES native module loading to remove external dependencies. As I noted above, I could make a build setup that creates separate builds without duplicating code to maintain compatibility with existing functionality while also offering ES module loading.

I think it would be better not to have a separate fork just for ES module loading, but it's not a big deal either way.

I'll add the build setup to my fork to eliminate duplicated code.

What problem are we trying to solve?

[robertdmunn]

I made a build setup using grunt. I left all the prod code in the same places and I made a src folder to hold source code for code that needs to support the ES6 module format. Just:

$ grunt

at the root to build prod files. Note that the files that don't need to be modified are not in the src folder, e.g. reactive-native stuff, etc. Maybe not a good long-term solution but gets the code working without duplication.

I'll probably just leave it this way in my repo unless there is motivation to change it.

[ericelliott]

You shouldn't need grunt. Just use the npm scripts. I don't think I'd want to accept a PR that bloats and complicates the repo unnecessarily.

[robertdmunn]

Cool, I'll let you know when I have it done.

[robertdmunn]

I finally had a chance to change the build tool to use the npm scripts. I have added a concat command to the scripts that does the same thing grunt was doing. I've also removed all the grunt dependencies and added concat-cli in devDependencies.

I don't have any new tests at this point, but I have confirmed that the es6 module generates cuids in the browser.

The existing tests outlined in CONTRIBUTING.md are passing as of my last commit.

Code is in the same branch as noted previously:

https://github.com/robertdmunn/cuid/tree/es-module

There are a couple of extra line feeds in the lib files, result of the concat process. Still functionally equivalent, though.

[Gin-Quin]

Nowadays the best practice to write libraries is as bundless ESM modules with Typescript types.

It's future-proof as CJS is slowly making its way out. And you can import it directly in browsers.

[ericelliott]

I've explored a bunch of different approaches, and it looks like the only good path forward I have found is to create a separate import for native ES6. It would look like this:

import cuid from 'cuid/esm/cuid.js';

Do you all like this approach? The major bonus is that it should not break anybody's build, whereas all the other options I have looked at would. 😢

This is the path we chose to bring riteway into 2022.

[ericelliott]

Nowadays the best practice to write libraries is as bundless ESM modules with Typescript types. It's future-proof as CJS is slowly making its way out. And you can import it directly in browsers.

We care a LOT more about avoiding breaking changes for the 3 million builds/month that rely on cuid than we care about future proofing, but we're close to implementing a solution.