Continuous Release with pkg.pr.new and esm.sh

[limzykenneth]

Increasing access

This does not affect end user necessarily. With continuous release, we can create testable CDN hosted build of the library per push/PR so that features that are inactive development (eg. p5.strands) can be more easily tested without needing to wait for a beta release or some kind of local build and distribution.

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
• Internationalization
• Friendly errors
• Other (specify if possible)

Feature request details

Continuous release for p5.js will involve two services, pkg.pr.new and esm.sh. The way that it works is by first installing the GitHub app for pkg.pr.new and setting up the relevant CI hook, this will then run the build and publish the same set of artifacts we publish to NPM to pkg.pr.new, this includes the CDN files that can be used in <script> tags. However, pkg.pr.new itself only replicate the behavior of NPM and does not host the files as a CDN, in this case we will need esm.sh which serves the files from pkg.pr.new as a CDN to actually serve the built p5.js library files, this happens automatically.

A few things to consider:

• To ensure only approved versions of the library are built, the CI workflow should be set to require maintainer approval so that maintainers can review the changes before allowing the build to proceed.
• The automatic comment left by pkg.pr.new on PR upon successful deployment will need to be customized to provide link to the esm.sh version as well.
• The esm.sh link will need to use the "Escape hatch: raw source files" link of https://raw.esm.sh for p5.js files to enable it to be used as <script> tag src property value.

One potential problem this can have and we want to avoid is for these WIP builds to be used as some kind of default version somewhere, if we publish these, they must be used for contributor testing purposes only and shouldn't be considered officially supported versions. They must not be used in any production environment.

---

This issue is a request for comment, please do leave feedbacks or questions if there are any, but do not ask to be assigned.

[saurabh24thakur]

I want to work on this issue .Please assign it to me..

[limzykenneth]

@saurabh24thakur Please read the last line of the issue.

[saurabh24thakur]

Oh, my bad @limzykenneth! Totally missed that last line in my rush to jump in..

I’ve gone back and read the full proposal now—the combo of pkg.pr.new and the raw.esm.sh escape hatch actually sounds like a clever fix for the <script> tag issue. It'll definitely make testing new features way smoother without the local build headache. I’ll hang back and follow the discussion here until it’s ready for the next steps..