I have a working setup for the core package that allows us to gradually migrate each entry point in core to ESM-only, at d7e572c

Platform

We're trying to use the neutral platform for all entry points, even though some contain Node-specific code and others contain browser specific code. The hope is that in the future the entry points can be universal, with shims for node+browser specific behavior.

Using the same ESBuild context for all entrypoints should also make the code splitting/chunking result better (which is a stretch goal currently), because it enables more entry points to share the same chunks.

The alternative is to have two esbuild contexts, one for the node platform and one for the browser platform. We're trying to avoid this, but it might become necessary once we start migrating more entry points. We'll see. 👀

`require`

While we can internally (and will) migrate all require/require.resolve calls to their import.meta equivalents, we can't guarantee that our (transitive) dependencies don't use require. Therefore we're still relying on an "CJS compatibility banner" in the ESBuild config, injecting require at the top of every file.

Side note: Depending on how many files we end up having, it would be interesting to optimize this so there is one file that builds and exposes this compat layer, that all files then just imports from via the injected banner. 🤔

Unified build script

We have a stretch goal of unifying the build setup for core and the rest of the monorepo, and currently I think that should be doable. The biggest difference is that core uses esbuild directly, while the other packages uses tsup, and we need to align on one of these (or tsdown 👀). Currently it appears that our build config will be a lot simpler, so it shouldn't matter much which we choose, but I might be too naive here.

Next steps

I've already migrated node-logger and client-logger to ESM-only succesfully. node-logger didn't have any require calls, but it had a bunch of dependencies that do and they still work.

My next goal is to migrate the manager and preview runtimes to the new structure, because they are distinctively different from the rest of the entry points today.

Side note: We should probably try to migrate away from using npmlog in node-logger, as it is both archived and deprecated by npm, and depends on other packages that are also deprecated. They're all CJS-only, so there must be better alternatives out there for us, especially given how little we use them.

Uh oh!

M2: Scripts adjustments #31817

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions