Export both ESM and CJS for treeshaking

[kraynel]

Q	A
Branch?	main
Bug fix?	no
New feature?	yes
Deprecations?	no
Tickets	/
License	MIT
Doc PR

Hi!

I recently used @api-platform/admin on a project. Great starter for an admin! I noticed that this library is not tree-shakeable. This means that even if I am not using graphql endpoints, the graphql library will be bundled and downloaded by the users. It is a whopping 43kb gzipped (see https://bundlephobia.com/result?p=graphql@15.0.0)!

I tried to embed both CJS and ESM builds in one package, with scoped exports to allow both node and a browser/webpack to find the correct package. Let me know if I missed something.

I tried a couple of builds: this reduces the gzipped bundled size by around 40kb when using an hydra endoint and up to 86kb when using a graphql endpoint.

Something nice if we want to continue in that direction would be to upgrade jsonld to ^5.0.0, they also generated an ESM version (https://github.com/digitalbazaar/jsonld.js/blob/master/CHANGELOG.md#added).

Please let me know if I need to change anything.

[kraynel]

I just realized that by moving the build to 2 subfolders /lib/cjs and /lib/esm this will break imports for people using full path like import parseHydraDocumentation from '@api-platform/api-doc-parser/lib/hydra/parseHydraDocumentation';

I see 3 options:

1. Keep it like that, update the doc & release a major.
2. Continue building cjs in /lib, but build esm in /lib/esm. Not ideal, it will mix both distributions.
3. Continue building cjs in /lib, but build esm in /dist for instance. Not quite as clean as option 1, but not breaking and both builds are not mixed together.

What do you think?

[dunglas]

As this lib is still a 0.x version, I'll go for the tiny BC break.

[dunglas]

Thanks @kraynel !