`p5.VERSION` reports "2.3.1" in the 2.3.3 release build (build-time version replacement regression)

[haukun]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• WebGPU
• p5.strands
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

p5.js version

2.3.3

Web browser and version

Any (issue is in the published build artifact, browser-independent)

Operating system

Any

Steps to reproduce this

Description

p5.VERSION in the published 2.3.3 build reports 2.3.1 instead of 2.3.3.

The source keeps the version as a build-time placeholder:

// src/core/constants.js
export const VERSION = 'VERSION_WILL_BE_REPLACED_BY_BUILD';

So the value is injected during the build/release step. In the 2.3.3
artifact this placeholder was replaced with 2.3.1 rather than 2.3.3,
which points to a regression in the release version-replacement step
(2.3.2 was correct).

Steps:

1. Load https://cdn.jsdelivr.net/npm/p5@2.3.3/lib/p5.min.js

2. Run console.log(p5.VERSION) in the browser console

3. Observed: 2.3.1 — Expected: 2.3.3

Evidence from the published CDN artifacts

Extracting the 2.x.x version string literal embedded in each minified build:

• 2.3.3 lib/p5.min.js → embedded version literal is 2.3.1 (wrong)
• 2.3.2 lib/p5.min.js → embedded version literal is 2.3.2 (correct)

package.json version is correct in both (2.3.2 / 2.3.3), so only the
in-bundle VERSION constant is affected.

Snippet:

function setup() {
  createCanvas(100, 100);
  console.log(p5.VERSION); // logs "2.3.1" on p5.js 2.3.3
}

[welcome]

Welcome! 👋 Thanks for opening your first issue here! And to ensure the community is able to respond to your issue, please make sure to fill out the inputs in the issue forms.

For guidance on contributing, check out our contributing guidelines and other resources for contributors.
💬 If you have questions or need support, feel free to join the Processing Foundation Forum or visit our Community page.
📜 Please also review our Code of Conduct to understand our community standards.
Thank You!

[scs0209]

Quick update on this one. It's not a bug in the version replacement code. rolldown.config.js and the release workflow are byte-for-byte identical between 2.3.2 and 2.3.3, and 2.3.2 was fine. The 2.3.3 bundles were built while package.json still said 2.3.1, and they made it out anyway. If package.json has the right version, the build embeds it correctly (checked locally), so the code is OK.

To keep this from happening again I opened #9207: a check that runs right after the build and fails if any bundle still has the VERSION_WILL_BE_REPLACED_BY_BUILD placeholder in it, or if the VERSION that got embedded doesn't match package.json. It's hooked into the 2.x release workflow and the continuous release workflow, plus a unit test so nobody hardcodes a version in the source and package.json stays the single source of truth.

This would've caught the 2.3.3 mismatch before it went live. If maintainers would rather do this differently I'm happy to rework it.

[Vaivaswat2244]

Hi @scs0209 @haukun, thanks for the report.

The workflow run for v2.3.3 built correctly. The assets on the GitHub release have VERSION = '2.3.3' and a September 7 banner. That run failed at the "Publish to NPM" step and never published.

p5@2.3.3 appeared on npm ten minutes later, and its bundles have the banner p5.js v2.3.1 July 30, 2026. So the tarbal was published manually from a machine with a stale lib/ ..

I think this was just a slip during publishing rather than a bug in the version replacement. To prevent it, a prepublishOnly step that runs npm run build should be enough for now, maybe with a version check on top. #9207 has a start on the check and I've left notes there. @limzykenneth @ksen0 could you confirm the direction before it moves further?

[Vaivaswat2244]

Also, @scs0209 one small request for next time: before opening a PR, please wait for the approach to be discussed or approved here on the issue. It saves your effort in case the direction changes. The contributor guidelines cover this in more detail.

[scs0209]

Also, @scs0209 one small request for next time: before opening a PR, please wait for the approach to be discussed or approved here on the issue. It saves your effort in case the direction changes. The contributor guidelines cover this in more detail.

@Vaivaswat2244 Thanks for the feedback! That makes sense.

I’ll make sure to discuss and confirm the approach here before opening a PR next time.

For now, I’ll wait for the direction to be confirmed here and update #9207 accordingly.

[limzykenneth]

There was some problem with the release of 2.3.3 which caused a few problems. These should be fixed with the next release and does not at this point need additional PR for fixes. Thanks.