Most appropriate sub-area of p5.js?
p5.js version
2.2.3
Web browser and version
Chrome 148.0.7778.179 (Official Build) (64-bit)
Operating system
Windows
Steps to reproduce this
Declare a local variable inside a p5.strands shader callback using a name that matches a p5.js built-in function (e.g. red, green, blue, brightness):
let myShader;
function setup() {
createCanvas(400, 400, WEBGL);
myShader = baseMaterialShader().modify(() => {
getWorldInputs((inputs) => {
let red = 0.5; // red() is a p5 built-in
let green = 0.8; // green() is a p5 built-in
let blue = 0.2; // blue() is a p5 built-in
inputs.color = [red, green, blue, 1.0];
return inputs;
});
});
}
function draw() {
background(0);
shader(myShader);
noStroke();
sphere(100);
}Expected behavior
No FES warning. Variables declared inside strands callbacks are shader-local and never exist in the p5 namespace, they should not be checked for conflicts with p5 built-in names.
Actual behavior
Function "red" on line 6 is being redeclared and conflicts with a p5.js function.
p5.js reference: https://p5js.org/reference/p5/red
The sketch renders correctly (the shader works as expected - green sphere with color [0.5, 0.8, 0.2, 1.0]), confirming these variables are genuinely local and not conflicting at runtime. The warning is a false positive.
Additional context
The FES name-conflict check scans the entire sketch source, including arrow function bodies passed as arguments to strands API calls (baseMaterialShader().modify(), getWorldInputs(), etc.). It does not account for the fact that these callbacks are transpiled into GLSL shader code by the strands transpiler, they run in a completely separate execution context (the GPU) and have no relationship to the p5.js function namespace.
Natural, idiomatic variable names for shader work — red, green, blue, brightness, hue, alpha, noise, map - all clash with p5 built-ins and will trigger this false positive, making the FES actively misleading for strands users.
Possible fix
The FES should skip name-conflict checks for identifiers that appear inside the argument callbacks of known strands API functions (modify(), getWorldInputs(), getWorldPosition(), uniformFloat(), etc.), or alternatively suppress the check for any code within a .modify(() => { ... }) block.
Most appropriate sub-area of p5.js?
p5.js version
2.2.3
Web browser and version
Chrome 148.0.7778.179 (Official Build) (64-bit)
Operating system
Windows
Steps to reproduce this
Declare a local variable inside a
p5.strandsshader callback using a name that matches a p5.js built-in function (e.g.red,green,blue,brightness):Expected behavior
No FES warning. Variables declared inside strands callbacks are shader-local and never exist in the p5 namespace, they should not be checked for conflicts with p5 built-in names.
Actual behavior
The sketch renders correctly (the shader works as expected - green sphere with color
[0.5, 0.8, 0.2, 1.0]), confirming these variables are genuinely local and not conflicting at runtime. The warning is a false positive.Additional context
The FES name-conflict check scans the entire sketch source, including arrow function bodies passed as arguments to strands API calls (
baseMaterialShader().modify(),getWorldInputs(), etc.). It does not account for the fact that these callbacks are transpiled into GLSL shader code by the strands transpiler, they run in a completely separate execution context (the GPU) and have no relationship to the p5.js function namespace.Natural, idiomatic variable names for shader work —
red,green,blue,brightness,hue,alpha,noise,map- all clash with p5 built-ins and will trigger this false positive, making the FES actively misleading for strands users.Possible fix
The FES should skip name-conflict checks for identifiers that appear inside the argument callbacks of known strands API functions (
modify(),getWorldInputs(),getWorldPosition(),uniformFloat(), etc.), or alternatively suppress the check for any code within a.modify(() => { ... })block.