Meta: ES Modules for documentation / distributed artifacts

[cdata]

This is a follow-up to a related discussion in the downstream DAT SDK project repo: https://github.com/datproject/sdk/issues/55

TL;DR Please consider distributing this module (and others in the Hypercore ecosystem) as an ES Module, and prefer documentation that demonstrates how to use it as an ES Module.

In discussing this topic in the downstream project, it was suggested that I seek feedback from maintainers of these core projects that the DAT SDK is built upon. I am grateful for whatever feedback you core maintainers can offer.

The rationale from the downstream issue is copy/pasted here for your convenience:

The frontier of the JavaScript library-building community is moving towards expressing distributed libraries as ES Modules. Tools like Rollup.js and Node.js¹ are creating cowpaths for a package ecosystem where modules can be more easily/consistently imported in multiple environments by adopting the standard JavaScript module syntax.

On the one hand, I'm sure that a full-conversion to ES Modules would be a lot of work, and is likely not feasible given the sheer number of dependencies involved. On the other hand, it seems like it would be feasible to distribute an artifact that uses ES Modules so that others can consume the SDK that way, and to reflect that mode of usage in documentation.

In the long run, preferring ES Module-based packages will make it easier for dependent projects to apply optimizations such as sharing dependency packages with the SDK, tree shaking and code splitting. These optimizations may be possible today, but in order to apply them effectively we would need a comparatively intimate knowledge of the DAT SDK's dependency graph and all the errata to correctly bundle it.

The DAT SDK is a massive body of JavaScript. The more of it that can be consumed in a standard, consistent module format, the easier it will be to accept the byte cost it brings as a dependency.

Thank you for your consideration, and I look forward to hearing your thoughts on this issue.

¹ Node v12.17.0 "--experimental-modules flag is no longer necessary to use ECMAScript modules (ESM)"

And one suggestion for incrementally moving packages in this direction was also offered:

One approach could be to continue publishing as you are today, but also take advantage of the "exports" field in package.json to publish CommonJS and ESM in a way that advertises a different entrypoint depending on the context (legacy Node.js, modern Node.js or bundling tool).

[mafintosh]

ESM is still experimental in Node and will be for a long time. You can import CJS using ESM today (see the node docs).

Once it goes unexperimental in LTS we can revisit. Feel free to open an issue on our community repo if you want to track that.

[cdata]

Thank you for your considerate feedback @mafintosh , and thanks also for your work on these projects.

Although it is technically true that ESM is still labeled experimental in the current Node.js (LTS), the following points are worthy of consideration as well:

• In the latest release of Node v12 (LTS), ESM support no longer requires a flag
• ESM have been available in stable releases of all major browsers for a few years now

I will file a corresponding issue on your community repo.

Thanks again,

Chris