Library build and dependencies refactoring

[limzykenneth]

Topic

As part of a refactoring of the build and release process, there are some options that may need some discussions on related to some discussions around the implementation of saveGif() @jesi-rgb has been working on.

1. UglifyJS that we are using now is UglifyJS2 which does not support ES6 and later syntax. We'll need to replace it with either UglifyJS3 or terser. I'd personally prefer terser but would like to know if there's any other opinion about considering UglifyJS3 instead.
2. Currently we are using babelify as a browserify transform for code transpilation while recently @jesi-rgb has added grunt-babel to do the same. The main question here is, ideally we will only do one transpilation, so should it be done before bundling everything (so only transpiling p5.js source code, ie babelify) or after (including node_modules dependencies, ie. grunt-babel)?

Just tagging a few people I can think of off the top of my head but if you have some thoughts please share.
@Qianqianye @stalgiag @davepagurek @endurance21

[jesi-rgb]

I believe the last tag @/endu is not correct, you probably meant @endurance21!

[jesi-rgb]

The main problem has been stated very clearly. Currently we are having trouble making the build and it all comes down (as far as I'm concerned) to uglify not liking new syntax.

Given the options, I think it's better to first bundle → transpile, which will cause less issues down the line since all the necessary code is already considered.

Looking forward to hearing from the community!

[limzykenneth]

I believe the last tag @/endu is not correct, you probably meant @endurance21!

Thanks, corrected. Github autocomplete failed me 😄

[Qianqianye]

Thanks @limzykenneth and @jesi-rgb. I am adding the Build Process stewards @outofambit and @kungfuchicken to this conversation.

[endurance21]

I think the one of the main issue we encountered was with
"Static-fs", plugin that we are using.

This plugin is necessary to read the content of file and make it available inline while bundling.

If I am not wrong that plugin works with "babelify", so if we are intending to go with
Bundling ----then---transpiling , we would need to figure out the way static-fs will work.

Also some third party library is contains the "fs" calls too so we may need to perform static-fs work on those libraries also, but in current implementation the static-fs works only for our own codebase ( the default behaviour of browserify) and when we tried making it a global behaviour it thrown errors.

So just to wrap-up, we need to keep in mind that static-fs calls must be dealt when we are thinking any approaches to transpiling our code.

[limzykenneth]

static-fs is basically replacing something called brfs when it is implemented, they both do the same thing which is replacing the fs calls to be inline content. brfs is also a browserify transform so it will be running before bundling and so won't affect node_modules code.

[dhowe]

In addition to supporting current syntax, would be great to improve the build time (with, for example, $ npm run dev)
This (specifically the browserify:dev task) is currently so slow (close to 30 seconds on my system) as to make development rather painful

[limzykenneth]

In addition to supporting current syntax, would be great to improve the build time (with, for example, $ npm run dev)
This (specifically the browserify:dev task) is currently so slow (close to 30 seconds on my system) as to make development rather painful

Ah yes, there's some findings on that as well. The two most notable things that takes the most time are

1. The actual bundling (which currently includes babelify) of the library, ie. taking all the source and dependencies and put them into one file.
2. Prettier formatting the bundled code after it has been generated.

It would be a good idea to look into removing prettier entirely as well since it's been a bit problematic with version updates, so this will be one priority for improving build times for me.

[limzykenneth]

While trying to clean up the build some of the existing dependencies we have I find that, mainly polyfills, are supported by all our stated browsers except for Opera Mini. I had a quick look and found that Opera Mini supposedly doesn't run Javascript locally, which makes me doubt that it works with p5.js at all regardless of if we include the polyfills or not.

I can't test this as I don't have an Android device with me. Would someone here with an Android device try it out and confirm if p5.js (or even canvases) can work with Opera Mini at all?

[davepagurek]

I just tried it out. It looks like in the default mode, it still runs local js for canvases. If you change the settings to "Extreme Savings Mode", I think in that case it runs no local js, and all canvases break.

[limzykenneth]

I guess we'll leave it for now in that case. I'm going to have another go at trying to remove prettier and whether I manage to or not, #5792 should be ready for review and merge by then.