<p dir="auto"><strong>Do you want to request a <em>feature</em> or report a <em>bug</em>?</strong><br>
This probably is a feature request since the root of this is considering the build tooling and questions on how to proceed with my efforts.</p>
<p dir="auto"><strong>What is the current behavior?</strong><br>
No native ecmascript module output and the current build tools don't easily allow adding a  native ecmascript module build target.</p>
<p dir="auto">While investigating a workflow using a native ecmascript module version of React (and ReactDOM) in browsers I found no implementation which outputs native ecmascript modules.<br>
One can use a wrapped version of the transpiled versions with added export statements but transpiling would not be necessary for browsers supporting ecmascript modules natively.<br>
Even spread operators are supported by these browsers although they're not fully supported by AST generators or other tools due to the fact that the spec for that isn't finalised.</p>
<p dir="auto">After some test projects and different build tools I built a simple proof of concept which outputs ecmascript modules that can be used in modern browsers.<br>
The challenge (and question I have) is that the tools and settings used in the POC contradict the current build settings and tools.<br>
So I am wondering if this is something that can be added as a build target or that this is something that is better suitable for an external repo for the time being...</p>
<p dir="auto">I would love to make this happen but I would like to hear if this is something that is deemed worth while and if so in what would be the preferred way of implementing this.<br>
During my investigation I did not find an easy way of doing so without changing a considerable amount of code and build tooling. Making this a relatively high risk endeavour.<br>
Webpack vs Rollup, different settings needed for Babel, and named exports instead of CommonJS module.exports pattern to name a few, and all the effects those have on the build process make this somewhat complex.</p>
<p dir="auto">To clarify some things, these are links to the POC's:<br>
repo which outputs native ecmascript modules for React and ReactDOM: <a href="https://github.com/wearespindle/react-ecmascript">https://github.com/wearespindle/react-ecmascript</a><br>
repo with a minimal setup to test if a working app can be made these modules in a browser: <a href="https://github.com/PM5544/module-test">https://github.com/PM5544/module-test</a></p>

<p dir="auto"><strong>What is the expected behavior?</strong><br>
Preferably a build target for native ecmascript modules.</p>
<p dir="auto"><strong>Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?</strong><br>
not relevant</p>
<p dir="auto">Currently we only ship CommonJS versions of all packages. However we might want to ship them as ESM in the future (<a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="237665439" data-permission-text="Title is private" data-url="https://github.com/facebook/react/issues/10021" data-hovercard-type="issue" data-hovercard-url="/facebook/react/issues/10021/hovercard" href="https://github.com/facebook/react/issues/10021">#10021</a>).</p>
<p dir="auto">We can't quite easily do this because we haven't really decided on what top-level ES exports would look like from each package. For example, does <code class="notranslate">react</code> have a bunch of named exports, but also a default export called <code class="notranslate">React</code>? Should we encourage people to <code class="notranslate">import *</code> for better tree shaking? What about <code class="notranslate">react-test-renderer/shallow</code> that currently exports a class (and thus would start failing in Node were it converted to be a default export)?</p>