Made by AI, Directed by David Stein

Search
Creative Coding

p5.js 2.3.4 Fixes the Version Number That 2.3.3 Broke

A small patch with one consequential entry — `p5.VERSION` was wrong in the previous release, which is exactly the sort of thing that breaks silently.

2 min read

We covered p5.js 2.3.3 on September 21 for its GIF decompression-bomb fix and the Decorators API work. 2.3.4, released 25 September 2026, is a smaller patch — but it contains one fix worth knowing about, because the bug it corrects fails quietly.

What changed

  • p5.VERSION is fixed. Several contributors — @haukun, @Vaivaswat2244 and @scs0209 — tracked down a problem with the version constant that was “the result of a problem during the previous patch release.” So 2.3.3 shipped reporting the wrong version of itself.
  • A more helpful FES message when preload() is used is restored (@davepagurek). The Friendly Error System message had stopped appearing.
  • Missing TypeScript declarations fixed (@Pcmhacker-piro, reported by @m4lt3).
  • A further fix from @Pranava-Pai-N, reviewed by @limzykenneth and @perminder-17.
  • CI enabled for the stable branch (@limzykenneth), to improve the release process itself.
<script src="https://cdn.jsdelivr.net/npm/p5@2.3.4/lib/p5.js"></script>

<!-- Optional, for the WEBGPU renderer: -->
<script src="https://cdn.jsdelivr.net/npm/p5@2.3.4/lib/p5.webgpu.js"></script>

Why a wrong version constant matters more than it sounds

p5.VERSION is what code uses to make decisions about itself. Anything doing a feature check, a compatibility branch, a bug report template, or a “which version is this sketch running?” readout gets a wrong answer — and gets it without erroring.

That’s the worst failure shape. A library that throws tells you immediately. A library that confidently reports the wrong version means a compatibility branch silently takes the wrong path, and you debug the symptom instead of the cause. If you have anything that reads p5.VERSION, this is the reason to bump.

Notably, the cause was the release process itself, not the library code — which is why the accompanying fix is CI on the stable branch. That’s the right response: patch the bug, then patch the thing that let the bug ship.

The patch cadence is deliberate

The release notes say work continues in main toward 2.4, and that “this atomic patch makes bugfixes available sooner, following our recent approach to patch releases.”

Worth appreciating. Small, frequent, single-purpose patches are better for a teaching library than batching fixes into a milestone release. p5.js is used heavily in classrooms and workshops where “update to the latest” is the only realistic upgrade instruction, and where a sketch that breaks mid-session costs a lesson. Shipping a two-bug patch three days after the release that caused one of them is the correct instinct.

The WebGPU renderer remains an opt-in second script tag, unchanged here — still the thing to watch in the 2.x line.

Related Reading