ES6 Conversion Continued and Modularization

[jeffscottward]

Increasing Access

This is a pre-existing request whose discussion thread was closed and the conversation has fragmented.
Reopening to consolidate work and discussion here.

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build Process
• Unit Testing
• Internalization
• Friendly Errors
• Other (specify if possible)

Feature enhancement details

AIM: To enable tree-shaking of necessary code, organization, idiomatic style, and to lay a foundation for other future enhancements like WebGPU.

The latest conversation this is being continued from is here #6173.

[jeffscottward]

TASK LIST

• ES6 class conversions
  • Checked which still needs conversion
• Use import/export for modules
• Discuss communications around upgrading to modular packages for end users

[jeffscottward]

https://github.com/processing/p5.js/blob/main/src/app.js
@davepagurek It seems p5.js is already using an ES6 module system.

#6370 (comment)

p5 is intentionally a singular, big package for now for ease of writing. That's not great for distribution though -- there are some issues talking about splitting p5 into separate importable packages (so that one doesn't have WebGPU code in every build.) This is probably a blocker for releasing WebGPU code since many users can't run it.

What actually is the next step to splitting p5 into importable packages?

cc @asukaminato0721

[davepagurek]

I think from the earlier issue there are two related but different goals:

1. Be able to import pieces in a build system and let unused pieces be tree shaken away
2. Be able to build packaged p5 modules with some features omitted (e.g. no 3D mode for libraries like p5.play that only use 2d, or a production build without experimental features like WebGPU if we experiment with that.)

For (1), I suspect the biggest issue here is fact that there are create* methods on the p5 instance to generate things like p5.Vector, so currently everything is all tangled up. So to enable this, we'd need to think of a structure that lets you import p5 core without all those, but still enable it in an everything-included build for the p5 editor. Maybe that could look like a p5/core module, a p5/vector module, p5/dom, etc that one can import separately to import specific pieces that you create via constructors, whereas the create* helpers are imported only when you import 'p5'? Or a different design that achieves the same goals?

For (2), we should look at the instructions here https://github.com/processing/p5.js/blob/main/contributor_docs/custom_p5_build.md and see what no longer works. If it's just a few bugs, we can file issues for them and fix those to get this build process working again. If it looks like it'll be a bigger task to revive it, we might want to consider looking at a different build process for this. Another task is examining what the different modules are, and if those provide enough granularity -- e.g. I don't think we're able to separate out rendering modes here because 2D and WebGL are both core, so if we want to enable e.g. 2D only we'd need some code changes to dynamically build up the modes available to createCanvas/createGraphics at build time.

That's my understanding of the current state of this discussion, @limzykenneth does that all seem right to you?

[limzykenneth]

I have had some conversations with @Qianqianye about these as part of broader discussions around what v2 would look like for p5.js. There are a few steps we like to take before determining detail implementations (specifically to understand the base requirements we want v2 to have). I can try to list out a bit of my thinking here but they are not comprehensive as I have not spend the time to write them out fully or plan them out yet.

In no particular order:

• Be modular as much as reasonable - each functionalities in p5.js be implemented as a module that can be optionally not included with a core runtime that will always be included. New features, optional features, experimental features, addon libraries will all use the same system. We kind of have those in the current implementation but it is not necessarily done in an independent or semantic way.
• Support promises natively for loading and other initializations - anything awaited in an async preload will wait until they are resolved before runtime initialization
• Look at rollup/esbuild for build system with eye on possible customization - @jeffscottward I saw the suggestion about vite on another thread, vite is specifically built for frontend build/devops and uses rollup and esbuild under the hood, libraries are better served with using rollup/esbuild directly.
• A new documentation system that fulfil what YUIDoc currently does for us - we will want to keep inline docs as is but there is no other tools (that I know of) can generate structured JSON docs from JSDoc style inline documentation. This may need to be created (I have a prototype that we can start from).

These are some of the things I can think of right now which is by no means exhaustive, I also want to shout out to q5.js which I think is an interesting way for us to look at implementing something largely compatible while modern and performant. Looking into what is currently out there so we don't ignore or duplicate existing contributions by other contributors are important as well.

I think for now some experimentation would be fine to do with actual work on the library requiring a bit more planning and concensus building. We also would like to have this large undertaking be part of a compensated scheme (GSoC or Fellowship) if possible and are looking at organizing something towards these.

[asukaminato0721]

Here is some small points:

Currently all the class is bind to p5, for example, p5.Vector = Vector, then export p5. CJS style ESM

pros: p5 is the global context, and less import.
cons: hard to split, typing hint / code analyze is hard.

so I guess first do something like p5.sound is ok. export default Class then import them separately.

[jeffscottward]

Currently all the class is bind to p5, for example, p5.Vector = Vector, then export p5. CJS style ESM

pros: p5 is the global context, and less import.

cons: hard to split, typing hint / code analyze is hard.

so I guess first do something like p5.sound is ok. export default Class then import them separately.

This was where my head was at given my unfamiliarity with the code base. Trying to find an AI tool that understands the context like CodyAI (https://docs.sourcegraph.com/cody/use-cases#refactor-code-with-inline-chat) to blitz through the changes but @limzykenneth is probably right about governance and proper planning, AI or no.

As for my inspiration for rebooting the effort for a WebGPU future, just stumbled on this, so making a note for later.
https://github.com/pmndrs/detect-gpu

[jeffscottward]

Just checking in on this.
What's the process to move this forward?

[limzykenneth]

I have done some experiments towards this but at the moment there are no specific plans as we are focused on something else (that's not quite ready to be publicly announced yet). There are a few areas I'm looking for possibility of revamp (eg. async preload, renderers refactor, new addon API, etc), however we don't really have the capacity to take on a larger project like this until a later date.

[GregStanton]

@limzykenneth: You wrote that "vite is specifically built for frontend build/devops and uses rollup and esbuild under the hood, libraries are better served with using rollup/esbuild directly."

Has Vite's library mode been considered in this discussion? It seems they've recently added at least some support for multiple library entry points too.

Thanks in advance! I'm still learning about this myself.

[limzykenneth]

I was not aware of vite's library mode and it could be something to consider depending on some ease of customisability aspects. I have already got a rollup version running and passing all tests so I'm not really looking in that direction at the moment.

[lindapaiste]

I bet that we can get some ideas by looking into how d3 handles this. Their code is distributed in a bunch of different npm packages, like d3-scale, d3-array, etc. But there is also a d3 package (and build) which combines them.

• Explanation of various installation methods
• The main d3 package is just a bunch of re-exports
• Builds using rollup, with vitepress for docs

[GregStanton]

Hi all! I'm interested in attending the April 2024 contributors conference in Denver, and I'm wondering if anyone involved in this discussion will be there? Of the many ways I could spend my time there, one good option would be to work toward a better understanding of the future p5 build process, documentation system, or a new add-on API.

Specifically, I wonder if it might be helpful to experiment with some of this in a small library first. I'll need to work on each of these things for the Mathemagical.js add-on library anyway, and the most sensible approach is to adopt the same tooling and practices as p5 whenever possible. Plus, I'm new to this aspect of software development, so it'd be great to be able to learn from others and to collaborate during the conference.

If anyone would like to collaborate on this, please reply here! That way, I/we can mention it in the conference application, which is due November 30th. (I just got the announcement yesterday.)

P.S. If anyone is interested in collaborating outside of the conference, I'd be interested in that as well; however, I'll need some time to get out of the prototyping phase with Mathemagical, so the timeline for me is probably roughly the same either way.

[limzykenneth]

@GregStanton I'm not really ready to mention this too publicly yet but since you are interested I'll share briefly what I'm working on here. As mentioned above I have been looking into reworking the build which at the same time is actually looking into larger changes around the codebase, tentatively a p5.js 2.0. The work in progress is in my fork here which serves as a proof of concept for some of the things I'm thinking of.

I am gathering all the possible things that could be worked on such as addon libraries utilities, internal classes rewrite etc and I plan to put together an informal RFC early next year to work out final details with the community. The timeline I have probably will have this done before April next year so it probably won't go all the way the OSACC 2024. Also at this stage I want to figure things out on my own first before taking any public comments just so I can focus and work at my own pace which is why I'm not fully announcing this quite just yet. In the meantime you can definitely have a look at the forked branch linked above for some ideas around where things are headed, I'll be pushing anything I've worked on locally there and keeping it up to date with the main branch here periodically as well.

[GregStanton]

Thanks @limzykenneth for the preview!