P5.js: p5 npm module is not minified

[neefrehman]

Firstly I know that this issue has come up before, and is duplicative of #2920. However that issue was closed two years ago despite the problem persisting.

Currently installing the p5 module via npm to be used with a bundler causes the un-minified (>1.5MB) version of p5 to be used, instead of the much smaller minified version. More details are in this comment on the initial issue by @Streemo: https://github.com/processing/p5.js/issues/2920#issue-324608388

In the last two years I'm sure even more users have been using npm in combination with bundlers to create their work. From GitHub's data it looks like there are currently 5.4k projects using it, and from npm there are 67 other packages depending on it. Fixing this issue would help with performance across all these projects, and help p5 (and works created with it) be more accessible in low-connectivity regions and on low-powered devices.

Currently there are a handful of workarounds, which all have their own tradeoffs or problems:

1. Manually going into the package.json of p5 in their node_modules directory and changing the main field to point to /lib/p5.min.js — this works when building locally, but wouldn't work on a CI system that installs the dependencies, and also wouldn't persist when p5 is updated.
2. import p5 from "p5/lib/p5.min.js" — this is quite a manual workaround, and users would lose access to any helpers that require resolving to the main bundle (@types/p5, for example)
3. Using aliases to point to p5.min.js — this will have the same issue with helpers, and not all bundlers or frameworks let you introduce aliases.

It looks like a fix could be to make the edit from workaround number one directly in this repo, which I'm happy to open up a pull request to do and test, but that could give rise to other issues so wanted to open up a discussion first.

Most appropriate sub-area of p5.js?

• [x] Other (bundling)

Details about the bug:

• p5.js version: <=1.0.0

[limzykenneth]

@neefrehman Does importing the p5.min.js file reduces the output file size? Because this comment from #2920 indicates that it still generates a huge file.

[neefrehman]

@limzykenneth for me that solution works locally (using Webpack and it's splitChunks plugin), and I get a smaller output file. I'm sure there may be a difference between bundler setups, though.

[limzykenneth]

I guess for me the main thing is I don't use p5.js over NPM and so I can't say for sure if changing the main file to p5.min.js will break anything or not (NPM installs and CDN etc).

[neefrehman]

I also don't know the full ramifications, but to test things I've just tried forking the repo, making the change to package.json and creating a new test package. You can see the package here and the code-change here

I've installed the package via npm into two projects and tested them locally. They work totally fine in terms of p5 features and performance as far as I can tell. I can also confirm that it's using the minified version of p5 with a dramatically reduced bundle size.

As for the CDN, I'm not so sure about the process for deployment so couldn't say if there would be any side-effects. My gut feeling is that it should work fine, as the contents of the lib folder are exactly the same upon build.

Let me know if you're ok with the changes @limzykenneth, and I can open a pull request. Or if there are any more tests that you'd like done.

[neefrehman]

@limzykenneth I'm still keen to move tests forward on this if it's something you'd be supportive of. I guess the next stage would be to recreate the CDN deployment pipeline for my fork, so we can make sure that it works fine as well. Do you know where the details of that are?

[limzykenneth]

For me this doesn't seem too big or a change in general so I don't have much objection to it. @lmccart @outofambit @stalgiag Do you have any thoughts on this?

As far as CDN is concerned, after looking into it I don't expect anything to be affected there. Your fork is available from jsDelivr here if you want to test it out. CDNJS is a bit more manual but the publishing process is similar so if it works on jsDelivr it should work on CDNJS.

[lmccart]

this all seems reasonable to me. I think this is the line where the npm update is happening. it's a straightforward npm publish posting to the p5 account, so you could login to npm with a different account before running the build/release process to test and it should just work. here's the doc describing the release process

[neefrehman]

@lmccart I've just tried running npm run release while connected to my npm account, but am running into the following error in the bower-push task that tries to push to your p5-release repo:

remote: Permission to lmccart/p5.js-release.git denied to neefrehman.

I've tried running npm publish which works fine and does publish the built package. Is there any way for me to recreate the grunt release task without having access to your repo? I can't see anything about it in the docs. Currently it looks like the change would have to be merged and you would run that command when it's time for the next release.

[limzykenneth]

@neefrehman If you don't need to publish documentation or to bower, you can just run npx np or if you just want to publish to NPM npm publish as you have tried is fine as well.

Have a look at the release documentation if you want to run the fill release step with your own repos.

[neefrehman]

@limzykenneth thanks! not sure how I missed that section in the docs... So npx np and npm publish are working fine. If you're happy with this change being made upstream to I can open up a PR? Or feel free to do yourself it for the next release, as it's only one line.

[limzykenneth]

@neefrehman I think that's fine, you can go ahead and file a PR.