Preact: Web-compatible ES module build

[matthewp]

Hey @developit! I was wondering if you would be open to a new build that is ES modules compatible for the web? I have a branch of this working locally. It uses a small custom babel plugin that turns stuff like './util' into './util.js';

It works in Safari:

In my branch I run the babel plugin and put everything into dist/es/. This took me like 5 minutes, super easy. If you are open to adding this, there are a couple of options:

dist/es or some such folder

This would be the way I did it for my proof of concept. This means that browser users would use Preact with something like:

import { Component } from './node_modules/preact/dist/es/preact.js';

This would require no changes to your src/ codebase. If you wanted to keep src/ the way it is, this is the way to go.

preact.js in root folder

A bit nicer solution for web users would be if you added preact.js to the root folder and all it did was:

export * from './src/preact.js';

Or it could point to './es/dist/preact.js'. If you are willing to change your src/ modules to add the .js at the end and point to exact files in that way, then no Babel transformations would be needed.

Users would only have to do:

import { Component } from './node_modules/preact/preact.js';

Which is just a tiny bit easier.

Let me know what you think! cc @treshugart

[developit]

I'm actually hoping to produce a proper single-file ESM + ES5 bundle in dist/preact.esm.js. preact-compat does this, so it should just be a modification to the rollup config.

I think that would address the use-case, ya? :)

[matthewp]

Why ES5? If someone is using this bundle they are either using a module-compat browser or are using a build tool where they can transpile how they wish, right?

[developit]

The ES2015 source de-opts, I wouldn't recommend using it. There are also a bunch of build-time optimizations done that are skipped when using the source.

btw seeing that working untranspiled in safari is blowing my mind haha

[robertknight]

The ES2015 source de-opts, I wouldn't recommend using it.

Is that an issue specific to Chrome? If so, does it still apply when using the new V8 engine (Ignition + TurboFan) I wonder?

[developit]

It has definitely improved with Ignition, but there are still unsupported phi use of let or const issues I see when running from source. Also, the other issue is that it bypasses the build optimizations (crazy uglify setup). I think @matthewp's PR for the ES5 + ESM build is a nice solution since it provides an ES2015 build of the lib without relying on any ES2015 features besides modules.

[matthewp]

Note that my PR doesn't run it through the same uglify step. Do you want it to?

[justinfagnani]

I would love to see a pure ES6 distribution where app authors can compile their whole app in order to get browser support, perf gains, as wanted. If Preact needs to compiler out let and const for best performance, so do apps, no?

[developit]

@matthewp I'd like it to yes, but I can do that post-merge if needed. Right now the important uglify bits are done when generating preact.min.js, but I'd rather they be done in the beautified uglify step, and have that run via Rollup. Only issue is that Uglify doesn't support ES Modules. Not sure how to make that work.