Please provide an ECMAScript module

[techthumb]

CommonJS modules cannot be optimized with webpack, for example, and the bundle size of the application is potentially larger.

As of Angular 10, a warning is emitted when building an app that imports entities.

[fb55]

Happy to look into this. Do you have any recommendations for tools to use?

[pe8ter]

I roughed out a version of this. I couldn't maintain the JSON imports so I had to convert those files to TypeScript. I don't know if the emitted JavaScript will fit all the import usage patterns for your users, either.

I would note that build optimization is likely not to realize much savings with this library. The bulk of the library is the "entities" file and appears to be widely used, which would be hard optimize away. For example, I built my own private project which imports the entities library via the commonmark library (which uses decodeHTML()) and with the linked changes only saw about 7KB savings:

As published:
    Lazy Chunk Files                         | Names                |      Size
    442-es5.33b8c541748f93ee71c1.js          | -                    |  82.08 kB
    442-es2015.33b8c541748f93ee71c1.js       | -                    |  81.53 kB

With linked changes:
    Lazy Chunk Files                         | Names                |      Size
    989-es5.53d67f20b7709f9745de.js          | -                    |  75.62 kB
    989-es2015.53d67f20b7709f9745de.js       | -                    |  75.03 kB

I hope this helps and is not just noise.

[nuxodin]

The JSON imports are also a problem if you want to import this great lib from skypack.dev
https://www.skypack.dev/view/entities

[fb55]

I just released a new version, and decided against making it ESM-only. I am still looking for tooling to add an optional ESM version, but haven't found a good option yet (open to suggestions!).

For the original motivation of the issue: Webpack tree shaking supports CommonJS modules.

The new release doesn't eliminate the JSON imports yet, but that is on my list.

[fb55]

@pe8ter This is super helpful, thanks for looking into it. The new version actually would benefit from this quite a bit, as decoding now uses a separate data structure from encoding. Do you know of a way to actually generate two sets of files?

[pe8ter]

@fb55 I don't understand what the two sets of files would be. Could you clarify please?

[fb55]

Same as in your example output: One for ES5 (CommonJS), one for ES2015 (ES modules)

[pe8ter]

I see. You would need two tsconfig.json files with different compiler options and different output directories. Since this package is consumable by Node.js, you would need to choose which output is the default format and specify the entry point to that built JavaScript in your package.json. Anyone that needs an alternate version would need to configure their builds to specifically reference that version of the built code.

[jimmywarting]

I think you should make the switch and go ESM only
sindresorhus is converting all of his 1k packages sindresorhus/meta#15

A ESM wrapper isn't as good. It only masks the problem. commonjs won't go await as long as we keep supporting it. It's time to make the move

[fb55]

entities@4.0.0 is now a dual CJS and ESM module (no wrapper, just double the code). As entities is already written in TypeScript, it wasn't too difficult to add another compilation step for ESM.