Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update sketch verifier to check for redefinitions and print friendly messages #7326

Open
wants to merge 5 commits into
base: dev-2.0
Choose a base branch
from

Conversation

sproutleaf
Copy link

Addresses #7269

Changes:

  • Added a new function checkForConstsAndFuncs() that checks for redefinitions and prints friendly error messages
  • Updated unit test accordingly

PR Checklist

@sproutleaf sproutleaf marked this pull request as ready for review October 21, 2024 14:04
Copy link
Contributor

@davepagurek davepagurek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work on this! The one thing I'd want to get a bit of clarification on is some of the false positive cases -- I wonder if that's from treating some p5 classes as globals when they no longer need to be?

// reference on the p5.js website.
function generateFriendlyError(errorType, name, line) {
const url = `https://p5js.org/reference/#/p5/${name}`;
const message = `${errorType} "${name}" on line ${line} is being redeclared and conflicts with a p5.js ${errorType.toLowerCase()}. JavaScript does not declaring a ${errorType.toLowerCase()} more than once. p5.js reference: ${url}.`;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like we maybe lost a verb in here:

Suggested change
const message = `${errorType} "${name}" on line ${line} is being redeclared and conflicts with a p5.js ${errorType.toLowerCase()}. JavaScript does not declaring a ${errorType.toLowerCase()} more than once. p5.js reference: ${url}.`;
const message = `${errorType} "${name}" on line ${line} is being redeclared and conflicts with a p5.js ${errorType.toLowerCase()}. JavaScript does not support declaring a ${errorType.toLowerCase()} more than once. p5.js reference: ${url}.`;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I guess JavaScript does technically allow it in different scopes? We could consider saying "your code might not behave correctly" or "your code might behave unexpectedly" or something like that.

src/core/friendly_errors/sketch_verifier.js Outdated Show resolved Hide resolved
'toString',
'print',
'stop',
'onended'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The functions meant to be redefined by the user make sense. Out of curiosity where do the other false positive entries come from? Is that from looking at classesWithGlobalFunctions?

src/core/friendly_errors/sketch_verifier.js Outdated Show resolved Hide resolved
Copy link
Member

@limzykenneth limzykenneth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should be able to leverage the AST more as it gives more context and information about where and what things are defined

src/core/friendly_errors/sketch_verifier.js Outdated Show resolved Hide resolved
src/core/friendly_errors/sketch_verifier.js Outdated Show resolved Hide resolved
// in the p5.js library, either as a constant or as a function.
function checkForRedefinition(name, libValue, line, type) {
try {
const userValue = eval("name");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what this line is meant to be doing but we want to avoid eval() as the bundler generally does work well with it.

src/core/friendly_errors/sketch_verifier.js Outdated Show resolved Hide resolved
@limzykenneth
Copy link
Member

I've also just checked the dependency sizes, it seems acorn and to a slightly lesser extend zod adds quite a bit to the bundle size. Are they importable as treeshakable modules so we don't include code we aren't using?
Screenshot 2024-10-24 at 15 03 26

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants