Add FES warning for keyCode === usage to help transition from 1.x to 2.0

[amy-b]

Increasing access

This feature would increase access by making it easier for learners and users transitioning from p5.js 1.x to 2.0 to identify and fix breaking changes.

Most appropriate sub-area of p5.js?

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

Feature enhancement details

in p5.js 2.0, there was an important change to how key and code are handled to align better with the widely used web standards spec reference.

Previously, it was common in 1.x to compare keyCode directly to constants like RIGHT_ARROW and LEFT_ARROW.

if (keyCode === RIGHT_ARROW) { background(0); } else if (keyCode === LEFT_ARROW) { background(100); }

Though this works in 1.x, it no longer works in 2.0 due to the standardization update. Now, users must use:

if (keyIsDown(RIGHT_ARROW)) { background(0); } else if (keyIsDown(LEFT_ARROW)) { background(100); }

Problem: Many 1.x users are accustomed to using keyCode === without needing to reference documentation. Since this behavior no longer works in 2.0, it can be confusing and lead to subtle bugs when transitioning projects. This can be particularly frustrating for those who rely on prior p5.js experience.

Currently there is no warning given when keyCode === is used, which can be harder to debug.

Proposed Solution: Add a Friendly Error System warning that:

• Detects patterns where keyCode is compared using === or ==
• Shows a warning suggestion to use keyIsDown() instead
• (Maybe) link to the updated documentation for keyIsDown()

Possible warning message: keyCode === is deprecated in p5.js 2.0. Please use keyIsDown instead. See https://beta.p5js.org/reference/p5/keyisdown/ for more information.

[welcome[bot]]

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. Thank you!

[ksen0]

Thanks for finding this @amy-b !

Thinking along with the proposed solutions: in this example, multiple usages should still only cause a single warning. The example here is not an error on 2.0, it just doesn't behave as expected. There definitely can be intentional uses of keyCode but in this case, the types on either side of === might help find accidental 1.x style uses.

@perminder-17 Do you think the reference should list LEFT_ARROW and other constants more explicitly somewhere? Seems too noisy to list in the "Constants" section but maybe in key? The keyCode section links to keycode.info but key() seems to be missing a list (e.g., "The system variables BACKSPACE, DELETE, ENTER, RETURN, TAB, ESCAPE, SHIFT, CONTROL, OPTION, ALT, UP_ARROW, DOWN_ARROW, LEFT_ARROW, and RIGHT_ARROW are all helpful shorthands for the special keys.")

[perminder-17]

Hi @amy-b,

Thank you so much for bringing up this concern. You’re absolutely right, without a clear, friendly error message, users may be puzzled by the changes to keyCode in p5.js 2.0.

I apologize for having overlooked documenting code; it functions just like key and accepts the same constant values. https://github.com/processing/p5.js/blob/c39ad5c452d773a18de4c03067a7315422442eb4/src/events/keyboard.js#L463-L465

In the source (see keyboard.js), we can now compare constants like this:

if (code === RIGHT_ARROW) {
  // operations...
}

I will promptly add documentation for code. Also, from my thinking I agree that your suggestion makes perfect sense. I think we need a friendly error message, and I would welcome further discussion on the ideal wording if everyone in the community agrees to have it.

Perhaps something along the lines of: “In p5.js 2.0, keyCode only accepts numeric values. To compare against a constant, use code === CONSTANT or keyIsDown(CONSTANT). See https://beta.p5js.org/reference/p5/keyisdown/ and https://beta.p5js.org/reference/p5/code for more information.”

Also, @ksen0, I believe the most appropriate location for this information is in the sections where constants are used for comparison. While the “key” documentation already covers usage with named keys, adding this detail to the “code” reference page would be ideal if you agree. It's just a thinking of mine, I don't know If I am correct :"). Also, I apologize for having overlooked this during the initial documentation, and I will open a PR shortly to ensure that “code” is properly documented. Thank you for your guidance and patience.

[IIITM-Jay]

Thank you so much @amy-b for pointing this out and I agree it's worth addressing this issue. Also, thanks to @ksen0 and @perminder-17 for the discussions so far on this.

From the Friendly Errors perspective, I think this is a great opportunity to improve clarity for learners transitioning from p5.js 1.x to 2.0.

I agree with @kseno, As noted, keyCode === SOME_CONSTANT is no longer the recommended way to check key presses in 2.0 — but since it doesn’t throw an error and might silently behave differently, this can easily go unnoticed, especially by beginners who’ve internalized 1.x patterns. We could add a runtime warning in the FES that detects equality comparisons involving keyCode (e.g., keyCode === RIGHT_ARROW, keyCode == LEFT_ARROW, etc.) and show a warning such as:

WARNING:: In p5.js 2.0, comparing keyCode directly to key constants (like RIGHT_ARROW) may not work as expected. Consider using keyIsDown(CONSTANT) instead. See: keyIsDown Reference

This wouldn’t throw an error or block execution, but would gently alert users that they're using an outdated pattern — helping them shift their mental model with minimal frustration.

No doubt, type checks on either side of === can help distinguish unintentional 1.x usage from legitimate patterns. Also, It might be helpful to include this check only if the comparison uses known key constants like LEFT_ARROW, UP_ARROW, etc., to avoid false positives.