Update build process to use ES6 modules + Rollup

[aendra-rininsland]

Nature of issue?

• New feature request

Most appropriate sub-area of p5.js?

• Other (specify if possible)

New feature details:

See my comment here on #2244. Effectively, updating the build process to use ES6 modules would modernise the codebase, enabling smaller bundles and more flexibility in terms of how people use P5 in their own build process.

[Zalastax]

This is a solution to the problem in #522, right?

Rollup is nice in that it has support for multiple export types.
It creates small bundles and doesn't require any polyfills. Do we know how far away we are from a code base that could use ES6 modules?

For direct inclusion in the browser we would create a bundle using UMD. This bundle would just be included in the zip-file directly, and not referenced from package.json. I don't think there's any point in using a browser field.

For usage as a npm library we would get create two bundles: CommonJS and ES6-modules.
Doing this is very easy, we just need two different fields in package.json. This would be very similar to the rollup-starter-lib example.

[aendra-rininsland]

@Zalastax That would indeed help #522, though providing the sources in the npm package as per #2244 would also solve that — it's the difference between import something from 'p5/lib/something' versus const something = require('p5/lib/something') — you don't need to convert to ES6 modules to benefit from that, any build process supporting CJS would be able to already do that if you supply the sources in the npm package, but using ES6 modules would optimise the bundle more due to the static analysis requirement (thus enabling dead code removal/"tree shaking").

Also, as you've mentioned, yes, setting the module/js:next field in package.json enables tools like Rollup to get at the modular sources while still providing a UMD bundle for browser consumption via the main field (considering much of the docs for P5 use globals provided via UMD this is probably preferable to building a separate CJS bundle and setting that as main as per rollup-starter-lib, IMO — UMD can be consumed as CJS and it's likely most people wanting to use modular bits of the lib will be using tooling that can consume ES6 modules). Also, AFAICT, using ES6 modules when referenced via the module field is preferred over CJS.

[sakshamsaxena]

@Aendrew Hi, apologies for the late arrival 😄

but using ES6 modules would optimise the bundle more due to the static analysis requirement (thus enabling dead code removal/"tree shaking").

I'd suggest you checkout the "modularisation" task I set up last summer. It didn't really gain any traction then as it was a seldom discussed feature. However, your arguments gave me the impression that it might really help you out. You can find some background here and here. If you look at the task code closely, you can see that it prepares the necessary files to bundle and then essentially passes the list to Browserify, which is being used programmatically. I think Rollup can be used programmatically as well, and maybe a fork of this task can be potentially worked upon to include Rollup for building.

I might be terribly wrong/off point here, so kindly correct me if it is so 😄 Would love to take this discussion further 😄

[meiamsome]

Are there any issues with the nature of the way p5 is built? What I mean is that all the sub-packages just add functionality onto the p5 object. I could see this being a bit weird to use as an import - would we want import { httpDo } from 'p5' or import { httpDo } from 'p5/io' or perhaps import httpDo from 'p5/io/httpDo'

[Zalastax]

@sakshamsaxena, yes rollup can be used programmatically :) The tricky thing is probably to restructure code to use the right module format. We will have to do all the restructuring first, and then when it's all done we can switch the bundler.

@meiamsome, the neatest solution to this problem that I've seen is the way RxJS does it. They have structured their project so that you can choose between patching the object or using free functions. They describe how it works on their website. I think they also do some re-exporting so that at least two of your suggestions both would work.

[meiamsome]

That looks like an excellent example of how to do it, @Zalastax! Do we think we can do the conversion in parts or will we have to rewrite the entire codebase at once?

[limzykenneth]

@meiamsome I believe you can include babelify as a transform in browserify so you can use es6 import in part of your codebase (babelify will transform them to commonjs require before passing to browserify), you won't get the benefit of tree shaking I think but you can start converting the codebase gradually that way.

[Zalastax]

Should we just add support for ES2015 modules or a full ES2015 transform? Is there a roadmap for the codebase?

[limzykenneth]

I don't think there's a roadmap yet. To be honest I'm a bit wary about a full convert as it means we will need to babel the whole codebase for compatibility, I much prefer to introduce new features as they become more supported worldwide (ie. less people using IE 😨 ). For example let is actually fully supported on IE11 so we should be able to introduce it with no problem and no conversion needed while retaining their benefits.

What do you think?

[Zalastax]

The env preset already makes sure that there are no conversions for features that are supported in all our target browsers. Since Babel only transforms syntax (like arrow functions), using newer features shouldn't inhibit a big cost. I think we should avoid babel-polyfill though, since it is quite large. http://babeljs.io/ has a brief list showing what you get from the transpilation and what you get from the polyfill.

[stephanmax]

@Zalastax I would love to see this coming to p5, please let me know if I can help.

[Spongman]

does anyone have a solution to the fact that what p5.js does - define a single class across many files - doesn't seem to be well supported by es2015 modules or ES6 language features?

[Zalastax]

I don't think there are any problems with augmenting the p5 "class" from multiple files - modules can handle it fine.
If we want to use classes, this is one method of doing so. I basically did exactly this in another project and as you see it's even compatible with TypeScript!

I suggest we start by just replacing browserify with rollup (no babel). YUIDoc already supports ES6 and modules so the change shouldn't break anything.

[Spongman]

yeah, that's kind of what i was worried about: every method definition requires at least two additional lines of boiler-plate just to shoehorn it into the prototype. i guess i'd like to see a complete example of a class defined in, say, 3 files with functions in each referencing properties & methods in the other files. i don't know that this is even possible in typescript without defining everything as interfaces due to issues with reference cycles.