[p5.js 2.0] Investigate replacing dependencies

[error-four-o-four]

Hey there,

First of all: congratulations and thank you for releasing 2.0

I've been looking through the dependencies in the package.json file and thought that it might be possible to reduce the weight of the node_modules folder and its contents (208 MB). Additionally this could result in a smaller bundle and speed up the build and tests. See the list down below for further insights

Another Issue that caught my eye is the 'exports' field "./": "./src/app.js". The specifier "./" should be changed to "."

dependency replacements

[email protected] (7.85 MB) => chroma.js (396 kB)

file-saver@^1.3.8 (36 kB)

• depends on Blob.js which is not prebundled
• additionally all main Browser have built-in support of Blobs

[email protected]

• 9 years old (?)

[email protected] (38.5 kB)

• is not bundled / minified
• 6 years old

dev dependency replacements

[email protected] (670 kB)

• could be replaced by a single utility function

[email protected] (132 kB) => nano-staged (41.1 kB)

[email protected] (4.49 MB)

• MSW supports browser and node environments which seems to be a bit of an overkill for its used purpose in the tests

[error-four-o-four]

Another improvement would be to replace concurrently with npm-run-all2. The scripts would have to be changed a bit:

  // ...
  "dev:build": "rollup -c -w",
  "dev:serve": "vite preview/global/",
  "dev:global": "run-p -l \"dev:build\" \"dev:serve\"",
  // ...

see this branch

Concurrently relies on the packages 'chalk' and 'lodash' which are also quite heavy. Migrating to 'npm-run-all2' would save another 20 MB disk space.

And one could go even further and write a small node script which utilises the vite and rollup APIs and spawns the build and serve scripts as child_processes.

[limzykenneth]

For the following dependencies

• color.js cannot really be replaced with Chroma.js easily as Chroma.js has specific quirks that needs to be worked around plus color.js has a better extension functionality. Chroma.js also does not have display-p3 support which is needed for the HDR canvas feature. The implementation of p5.color itself provides flexibility to use different libraries if necessary so we can revisit this at a later point
• file-saver does not have a viable alternative and is relatively small after bundling (2KB minified)
• libtess there isn't a well maintained alternative
• omggif there isn't a well maintained alternative

For node_module size, especially from dev dependencies optimizing for size isn't really a goal. If the desire is to preserve disk space, using pnpm would be much more efficient than trying to micro-optimize individual dependency size.

[error-four-o-four]

Yes, honestly I didn't take a closer look at the implementation of color.js and it's capabilities in p5.js. Sorry for the hassle.

You're right, using pnpm would be the right way. Unfortunately pnpm isn't used very often.

Would it be an option to write the code to save image files?

[limzykenneth]

Would it be an option to write the code to save image files?

Do you mean for file-saver or omggif? I think for either there are some very new Web API standard that can possibly replace them eventually but at this point they are not widely implemented yet so they can't be used with p5.js until more widely available.

[davepagurek]

One other thing to mention: @perminder-17 was looking into replacing libtess with earcut here https://github.com/processing/p5.js/pull/7492, which is on pause because other changes were higher priority, but we intend to get back to that. it's not exactly a 1:1 change so we're looking into balancing performance and feature set. We haven't yet looked into its bundle size as a consideration though.

Our main space saving measure there was to allow 2D only users to not import WebGL at all, which should now be feasible as @perminder-17 also built a minimal filter runner for 2D mode. We haven't yet made an easily accessible (CDNed?) build like this, but that could be the lowest hanging fruit maybe?

[error-four-o-four]

I closed the original PR because I edited the changes directly on my local dev-2.0 branch (my bad) and made a new PR.

Yes, regarding the dependecies file-saver and omggif there's not much one can do except to wait until the Web APIs are more widely supported.

Regarding the dev dependencies I totally agree that it's not the (current) primary goal and that there are better ways but I also want to raise awareness that it's a tiny step to conserve ressources and energy by replacing some packages. Additionally these changes would also affect performance. Specifically concurrently, glob, lint-staged and msw need 22MB disk space which could be reduced to rougly 1.2MB by using npm-run-all2, tinyglobby, nano-staged and mentoss. (Doublechecked with pkg-size.dev)

After all there's a whole community which tries to improve the js ecosystem: e18e. They also provide great ressources and tooling like publint and arethetypeswrong

Regarding the easily accessible build I wonder if esm.sh would also be a viable option? But this should be a concern of p5.js-website/p5.js-editor

[JounQin]

npm-run-all2 is incompatible with Windows glob: https://github.com/bcomnes/npm-run-all2/issues/125

[GregStanton]

@error-four-o-four Thanks for your focus on this area! I didn't know about e18e, so I appreciate you sharing that 😃

[error-four-o-four]

adresses #7853

Hey there, I've been searching for repos which could replace pako and/or the inlined Typr.js.

It looks like fflate could be a proper replacement.

Additonally there's an existing, maintained, treeshakable fork of Typr.js which uses pako. One could ask if they'd be willing to switch to fflate

[error-four-o-four]

@ksen0 and Devops I'd like to know if there's any guideline about how to handle dependabot requests?