Build Server & Client Libraries with esnext and ES Modules

[drewpc]

Currently, the project uses Gulp and Babel to produce the server and client libraries required to be imported by anyone using react-server. That means those libraries are transpiled down to es5 and end applications can't ship esnext code to browsers as they see fit.

This issue proposes the following:

• Use Rollup to bundle client and server libraries ending in '.esm.js' as ES Modules. These libraries would not be transpiled by Babel, just bundled by Rollup.
• This likely will apply to the following packages inside react-server:
  • flab
  • react-server-core-middleware
  • react-server-data-bundle-cache
  • react-server-middleware-json-response
  • react-server
• Add these libraries to package.json so that Webpack can find and use the ES Modules version when building the final application for the end-developer.
• The end developer is then required to transpile the final application as they see fit.

All of this paves the way for further enhancements to how react-server leverages Webpack to bundle the final application and transpiles at compile time (not "publish" time for react-server). It further allows the end-developer to make custom decisions about what to transpile. For example, if all of the clients of my application use ES6 compatible browsers, I don't want to transpile everything down to ES5.

See the the article Webpack and Rollup: the same but different for conceptual details.

[roblg]

I think I'm in favor of this proposal. It makes sense to me to let react-server users ship ES6/esnext directly to browsers that support it.

I haven't thought deeply about what would be required from the technical side, but it seems like we'll probably want to ship both pre-transpiled and non-transpiled code for at least a little while to give existing users a chance to migrate.

Also, I assume that as part of this proposal we'd be renaming all the files in react-server to .esm.js?
And looking further down the road, if we're shipping untranspiled code, we'll probably want some way of communicating what level of ES we support in that code, to make it easy for users to know what all the need to transpile it, if necessary?

[drewpc]

@roblg My plan was to submit a PR that uses Rollup to generate a non-transpiled ESM bundle and a transpiled UMD bundle (same as what is currently being produced). No need to change any existing filenames to .esm.js...just the final bundle.

I was also planning to create an entry in the documentation on how to use the ESM bundle and that the implementer has to take ownership of transpiling any features as they see fit (i.e. recommend the Babel settings). I've been thinking through the question of "do we need to share what level of ES is supported in the code" in my personal projects and I think the answer, in general is "no, we don't." If I use ES6 in my project and React Server uses ES7, Babel will transform all of code to whatever the transform target is. If that target is ES5, then both ES6 and ES7 code is transpiled/polyfilled to ES5. If that target is ES6, then just the React Server ES7 code is transpiled. None of that is ever communicated by the React Server project though...just that fact that it must be transpiled by the end user...that's it.

[drewpc]

I'm planning to work on this over the next 2 weeks, so I'll have a rough codebase to share soon.

[roblg]

If I use ES6 in my project and React Server uses ES7, Babel will transform all of code to whatever the transform target is.

In this scenario, I was imagining that React Server would tell the user via docs "We're using ES7, so transpile that however you want.", or "We're using ES7 + <this one random experimental feature that has a plugin >", as a sort of contract between us and them. It'd be super annoying if users had to figure out what they needed to transpile by trial and error.

I thin the rest makes sense to me. 👍