Distributing custom builds

[davepagurek]

Topic

One of the things we designed into p5 2.0 was a module structure so that it would be possible to built p5 without, for example, the WebGL module at all. Although this system is in place, we still haven't decided how best to give that functionality to users.

Some ideas:

• We could package (minified?) versions of each module, so that you could have a multi-file p5 setup, and easily comment out the script tags for the ones you don't need
  • These could be toggled on and off in something like the p5 web editor's version picker ui (cc @raclim, if you have any thoughts!)
• We could make a script in the p5 repo where you specify which modules to include (or which to omit?) and then document that process somewhere
• We could maybe provide a web tool to do the above for you, e.g. on the download page on the p5 site. We could give you some checkboxes for modules to include, and then make a build for you that includes those.
  • Depending on how many options there are, we could pre-compute all of these at publish time so that each combination maps to a jsdelivr URL
  • If that's not feasible, we maybe have to do a build for you, which could mean having a serverside thing for this, which has other costs to consider

[alexf77]

Yes, this would be great. I am using p5 to animate a logo on a website. the minfied version is 1mb, which is steep for the logo

[GregStanton]

Thanks @davepagurek! Quick thought: How about add-on libraries? I seem to remember some discussion of a possible web-editor feature that'd make it easier for users to incorporate them.

Whatever user experience we want to aim for, maybe it'd make sense for it to be designed so that add-on libraries could be added just as easily as main p5 modules, but maybe with some way of distinguishing them (e.g. as an indication of stability, etc.)?

I guess add-ons can now use the same system as main p5 to add modules, but if those were to be incorporated into the custom-build process that users go through, that might affect the feasibility of some of the approaches you've outlined?

[davepagurek]

That definitely could work! Each module of p5 is already structured as an add-on, so if we're also planning on adding some more structure to addon imports, we could do something similar for core modules if we want.

[ksen0]

(Just my current thoughts:) Moving toward more add-on modularization seems productive, though I think FES support in add-ons would be a requirement (it's planned). In terms of increasing access, there's 2 benefits here:

• reducing size - support wider array of connections.
• beginner-friendliness - make it easier to navigate and include p5.js community libraries

However, the downside to beginner-friendliness is that initially I think this could be a bit extra friction to start with; though I think one of the benefits of modularizing via add-on libraries as suggested above is that it can create an easier on-ramp to the rest of the ecosystem.

While the comment-out-able list of scripts and checkboxes make a lot of sense for the website and the editor, maybe it's possible for the p5.js Editor to also "behind the scenes" include/exclude (by commenting out) unused scripts during editing, and then highlight that these are manageable checkboxes when share/download happens? This kind of proactive management opens another set of its own challenges, but I'm trying to think of ways to address the underlying needs (p5.js should be much smaller to import in many cases, but it should still be very easy to get started with).

(Including for context- There have been prior discussion of reducing bundle size via tree shakeability by design:
#5740 #7014 #4127 - however from these conversations, this looks like a major undertaking that is right now our of scope, but correct me if I'm wrong please.)

[limzykenneth]

One of the goals I'd want is for p5.js is to be able to run the build in cloud environment like in Cloudflare Workers then the users will be able to choose which modules to include then it will run the build to create the build they want. One of the things we need to define is which are the core modules that all modules need to have then we can eventually have a cloud sevrice that build this on demand.

I believe Rollldown is on this path and would like to see more experiment on this in general.