Feature request: Add a "module" entry in package.json to export ES2015 version of React

[misterfresh]

Do you want to request a feature or report a bug?
Request a feature

What is the current behavior?
React ecosystem was promoting ES6 classes and modules since 2014 and many packages like react-router, redux and so on, have an "es" folder in the npm package with source code in ES2015 modules. Unless I am missing something, it is strange that React itself does not offer that option.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://jsfiddle.net or similar (template: https://jsfiddle.net/84v837e9/).
Install react and try to import it in a browser with native modules enabled.

What is the expected behavior?
Have an "es" folder in the npm package with ES2015 modules source code, like most React ecosystem projects do. Allow to import react from ES2015 native modules to make developer workflow more simple.

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
All versions

[Haroenv]

The source code of react is still using a custom module system that is close to CommonJS and not using es2015 modules AFAICT. I assume this is why they also aren’t exposed.

[misterfresh]

For anyone bumping into this, it is possible to bundle CommonJS modules as native modules using the config in this file

[lukastaegert]

At rollup, we were made aware of this issue because you exposed a bug in rollup-plugin-commonjs. in a way, thanks for that 😉. But this would not have happened if react had had a module entry/ES6 export.

Given the recent improvements to rollup's tree-shaking algorithm (and there are more in the pipeline), at least for rollup users, exposing an ES6 bundle might have some positive effects on the bundle size depending on what react features are used. If you want to go there, such a bundle should ideally

• only provide named exports
• not create global variables

as this makes it easier for the tree-shaking algorithm to do it's work.

Even though I must admit I do no understand every aspect of react's build script, I would expect this could basically be solved by adding another build target with the correct format + possibly an entry point that has the right exports.

Btw. I noticed you are using a rather old version of rollup. If there is anything preventing you from updating, please file an issue! There is an interesting TODO comment here–is this still current 😜?

[Andarist]

@lukastaegert are named exports and default ones different in any sense? default is just a named export AFAIK, only treated differently when imported.

[TrySound]

@Andarist default export can not be changed in runtime. Named exports are bindings, so with let can be changed from file with them.

[lukastaegert]

Maybe my comment about named exports was a little cryptic, so I will elaborate. I was referring to the not uncommon practice of exporting things twice from a file–once as a named export and once as a member of the default export. The latter is what often prevents tree-shaking for the named export even though the default export is not used. The reason is that in the exporting file, the default export still needs to be assembled and if this assembled object is included in the bundle–which can happen easily for various reasons–all its members will be included in the bundle.

This practice probably stems from the fact that bundlers like webpack and indeed rollup's CommonJS plugin do this themselves when converting CommonJS files. Other libraries that do this include lodash-es. When you remove the default export from node_modules, bundle size after tree-shaking can currently be nearly halved (more would be possible with future improvements).

What does this mean for react? If you make it possible that this

import {Component} from 'react'

can be interchanged with

import React from 'react'
const Component = React.Component

then you always need to assemble the React object which in most likelihood will break most of tree-shaking for the whole package. However I understand that for these decisions, ease of use should always be preferred to premature optimisation. But it is a point to consider especially if you plan to move to a native ES6 modules in the future (which in my opinion you should).

[Andarist]

Ah, sure - this I understand and I'm aware of. I don't like though recommending only named exports as some kind of the rule of thumb. Way better is to just educate people about consequences of attaching things to the default one (hint hint your eslint plugin ;) )

However I understand that for these decisions, ease of use should always be preferred to premature optimisation. But it is a point to consider especially if you plan to move to a native ES6 modules in the future (which in my opinion you should).

Personally I do not see import {Component} from 'react' any harder to use, assuming it would be exported purely as named export (no attachment to the default one).

Migration to the newer export style could be easily run with a codemod and also a babel plugin could be created to allow people using class MyComponent extends React.Component {} syntax.

[Jessidhia]

@TrySound just a note: a default export is like any other export and can be changed at runtime. It's the export default statement that is the complicated one.

An export default of named function declaration or named class can be reassigned by reassigning to the function/class name, but otherwise it appears non-reassignable. But you can always do a mutable default export by declaring let Identifier and doing export { Identifier as default }.

Not that I recommend doing it as immutability is good for you.

[misterfresh]

For now I can make it work by manually re exporting the named exports in a separate file, then bundling that file with Rollup.

[gaearon]

I want to make it clear you're not going to get awesome benefits by "tree shaking" React. Most of the code is in the internals that is always used. You might at most shave off one or two kB, and only if your code never uses React.Children.

So this is not a high priority optimization for us for that reason.