search

paralleldrive / cuid

Collision-resistant ids optimized for horizontal scaling and performance.
Other
3.44k stars 123 forks source link

distribute as native ES module #120

Closed elf-pavlik closed 1 year ago

elf-pavlik commented 6 years ago

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 commented 6 years ago

Open to a PR

robertdmunn commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

robertdmunn commented 5 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.