ES6 modules

[tyteen4a03]

Hi, are there any plans to migrate this module to ES6 modules?

[blakeembrey]

Not for the foreseeable future, no.

[jarrodek]

Hey @blakeembrey would you accept a PR with an ES6 module for this library? Bundles widely support ESM so it doesn't make much of a difference for them. For a direct use (including in a web app to a global scope), well, with a breaking change devs have minimal work to do to upgrade to a new major version.

[blakeembrey]

I'd probably release it alongside a rewrite of the library. The main thing I don't want to be doing is maintaining two versions or breaking existing node use-cases. Since all supported node versions now have ESM support, it should be easier, but it's still hard for people to migrate.

[capaj]

but it's still hard for people to migrate.

why would they need to migrate?
If you add a module entry point to package.json and add pluralize.esm.js it will satisfy both ES6 and legacy consumers.

Of course it requires adding a build step, but that's trivial with microbundle or similar.

[friday]

You don't need to refactor, but you do need a build/bundle step. Just delete your module wrapper code and use rollup or something similar to bundle different versions. Reference those in package.json main, module (and web if you minify). You probably want to gitignore the folder you put them in.

The output from rollup is very clean.

[silverwind]

I'd be nice if the CJS exports of this module would be statically analyzeable, so things like https://github.com/nodejs/cjs-module-lexer can provide named exports when importing it in ESM.

If it would assign it's exported to module.exports, it will work in all environments. Stuff like AMD or globals (ugh) are no longer necessary in the modern JS world.