[Tracking] ESM-only spike 📦

[JReinhold]

🧑‍🤝‍🧑 Who: @ndelangen and @JReinhold

This is a tracking issue for the ESM-only spike 📦. The purpose of this issue is to keep tracking of the overall status of the project and tasks, and plan everything around it. It is a sub-project under #29038

The main purpose of the spike is to answer questions about what happens when we convert to ESM-only, and how that can happen. Answering some of these questions will require explorations and writing code. It is not the goal of this spike to merge the code into next, even if it backwards compatible. However it could potentially be part of v8.5. The reason for this is that we always underestimate the effort it requires to turn an exploratory spike-PR into a polished PR ready for merging.

As part of this we need to ensure that we're testing in a proper setting. Sometimes testing these far-reaching changes isn't enough in the monorepo, because the monorepo can have linking setup that makes the changes work, even though they wouldn't in a real setting. We must be mindful about when things should be tested in separate projects using Verdaccio or similar.

Tasks

Beta Give feedback

1. Write down how to figure out the answers to the questions @ndelangen

❓ Questions

What are the steps towards ESM-only, and in what order should they be done?

How can the migration be split into multiple milestones to avoid massive, unreviewable PRs?

Which of the steps can be carried out in a backwards-compatible way, potentially pre-9.0?

What is the right order of package migrations that will minimize failures?

How can we load presets?

Today we’re using esbuild-register, but that’s a hurdle because it assumes CJS-first - can we replace that with something else, like esbuild natively? How do we keep supporting TS, CJS and ESM presets?

Is bottom-first or top-first the best approach for migration?

1. bottom-first would be migrating the Storybook core to ESM, and make all other dependents import it via dynamic imports to force ESM usage. Then slowly move up the dependency graph, migrating one package at a time.
2. top-first would be migrating the bins to ESM, making Node.js go into "ESM mode", and then see what happens.

How does ESM-only affect Jest-based Portable Stories users?

We know that Jest in general is very heavy on CJS. Does going ESM-only break Jest-usage of Portable Stories, or is it still compatible? The upcoming release of Jest 30 might improve the situation.