We do intend to ship a ES module build of React in the near future. Because that's a breaking change that could require significant changes to existing apps (i.e. to update the imports), we'll likely wait until the next major release cycle.

However, note that tree-shaking probably won't help much in the case of React. React isn't a library of independently useful features; it's a cohesive framework where features work together. We also have a really small API surface area. So there's no much to "shake" apart.

Arguably the main `react` package would benefit slightly from tree shaking, but those exports are already really small. The `react` package doesn't contain that much implementation; it mostly just calls into internal React DOM to schedule updates.

you can ship both commonjs and es modules using export maps, so it doesn't have to be a breaking change. You can use export conditions.

anyone who cares enough will opt in to use es modules, of this I'm certain.

Is there a reason that is not being considered?

Agreed that having React available as native ES Modules would be good. There's an open issue on that:

https://github.com/facebook/react/issues/11503

However, there really isn't anything to tree-shake in React. The renderer implementation is effectively a single consolidated set of logic that handles all work for all types of components. So, there's no unused functions to get shaken out.