[v3] export modules from index

[legobeat]

• Targeting Version 3 #125

---

If there's going to be declarations and stuff for an entrypoint in the manifest, might as well export the modules from it?

• Export modules from index.ts.
  • Allows e.g. import { aes } from ethereum-cryptography
• docs: update import examples to use package export paths

[paulmillr]

Not a big fan of this. Let's keep it the same way other modules are kept.

We can revisit after full transition to ESM.

[legobeat]

Not exporting is fine, I guess!

We can revisit after full transition to ESM.

Hmm, is this planned anytime soon and would that mean not exposing CJS builds? As ESM can not be used by CJS code, I would hope that CJS support can be maintained in the long-term <3

[paulmillr]

ESM can not be used by CJS code

that’s not true anymore for nodejs v22.

Overall, people need to transition to esm at some point. It’s natively supported im browsers and allows to load packages without any bundlers, which is a big deal. It also allows us to simplify working with deno, bun, deno’s esm only package manager, etc.

I wouldn’t want to start doing that until nodejs v18 is deprecated. And I wouldn’t do that unless the community is okay with it in general.

[legobeat]

Got it, thank you for explaining the rationale! Might be worth considering that extended support for Node.js v18 will be provided for users of among others:

• Debian bookworm (EOL 2028-06)
• Ubuntu 24.04 LTS (Standard Support ends 2029-04; Legacy Support ends 2036-04)
  • For illustration, they still do provide extended security maintenance updates for Node.js v4 for 16.04
• Amazon Linux 2023 (Support for nodejs v18 until 2028-08)
• Enterprise Linux (RHEL, SUSE) typically provide extended support as well but I couldn't find up-to-date info on those easily
• Various independent vendors provide OS and container images and deployments with independent maintenance support

So for these users, Node.js v18 will not actually be deprecated during 2025 and some users will expect to keep using their supported runtime versions beyond the upstream maintenance window.

Not meaning to imply that ethereum-cryptography should match all of these (or even strictly needs to consider any of it, though it would be nice¹), just that "when nodejs v18 is deprecated" is not an entirely black-and-white question and hopefully bring some nuance to the ESM-only timeline consideration.

Footnotes

1. If it were me, I think it could be a good target to aim at having if not mainline then at least critical and security-related bugfixes backported to a major version runtime compatible during lifetime of Debian bookworm (2028-06) if not also Standard Support for Ubuntu 24.04 LTS (2029-04). Or if not that, at least until both distros have new stable/LTS versions providing newer Node.js versions (~2026?). This is considering users who are comfortable using the vendor-provided versions but where either nvm, or "compile it from source" are non-starters (for compliance reasons or otherwise). And if we're doing that, I imagine that maintaining two separate build systems will not be worth the headache.... ↩

[paulmillr]

Thanks for the info, it's quite useful for future planning.

One thing to keep in mind is that even if we decide to do ESM-only stuff, the old hybrid versions would still be working. Just like eth-crypto v0.1 is still used by legacy systems.