Hi!
It sounds like the Dreamweaver editor you’re using is checking your code to a stricter level than whatever tool you previously wrote it with.
(This is often referred to as linting.)
The history of JavaScript’s rapid scrappy initial development in the browser means that there are various things that browsers will actually tolerate in your code (e.g. not declaring variables before they’re used) which are nonetheless not recommended as good practice as they can end up contributing to hard-to-find bugs as your programs get bigger.
This particular editor is set up to help you find these - to help you write better code.
solution 1: turn off the checking (not recommended)
It’s likely possible to turn off this checking - it’d often be referred to as a “linting” step.
However, if you can instead afford to take the time to fix up the issues, that’s what I’d recommend. You’ll have higher-quality code with fewer potential bugs, you’ll learn a lot in the process, code you write in future will be better, and it’s also quite possible that it’d be perceived better by your assessor if 1: your code is to that higher standard and 2: you show awareness in a write-up of this distinction in standard, and some of the specific causes that you learned about and resolved. So…
solution 2: work through the errors one by one (recommended)
I appreciate it can be overwhelming to get a lot of errors at once for code that was perhaps working fine.
I recommend just taking it error by error starting with the first one and ignoring all the others until you’ve fixed that error (i.e. made it go away, and ideally understood it). Some are probably flagged as errors, while some might just be flagged as warnings that you don’t strictly have to fix (probable example: “x is defined but never used”).
At a guess, it looks like Dreamweaver uses something called ESLint to do its linting for you. ESLint’s default rules are documented here. For example, here’s the rule that checks you have no unused variabes in your code.
These explanations can be formal and a bit tricky to read, I admit, but generally offer the thinking behind the rule, and examples of good and bad code as relate to this rule.
errors about undefined p5 variables and functions
If, however, the editor is complaining that all the p5 variables (such as mouseX or fill() or circle()) are not defined, then the conversation is a bit different and the editor is not sufficiently well configured to help you and is flagging a lot of non-errors. Some configuration will be needed to inform the editor about those variables and functions. Let us know if that’s the case and we can advise.
An example LLM prompt for learning from chatgpt, etc
If you’re allowed to use LLMs like chatGPT then you can ask it to explain to you what each error means, in the abstract. Here’s a possible prompt:
“I have written a javascript p5.js sketch which is working fine in the browser, however in a new code editor it is complaining that “x is not defined”. I don’t want you to fix my code because it is for a class, so i won’t show you my specific code. Instead, can you give me a very short hypothetical example of when that specific error might come up, what it means, and how it should be corrected?”
You can then adapt that prompt for each error that you don’t understand, by replacing the bit about “x is not defined”.
aside: dreamweaver editor vs, say, vscode
I should also say that (unless mandated by your class) you don’t need an editor as complex as dreamweaver to put your sketch on a website, and it’s possible that the dreamweaver environment adds a lot that can confuse. It can be clarifying and educational to try to build the html page from scratch with something like vscode (free). By default it won’t have a linting step, however, but it can be configured to run one when you’re ready. (That’s also the editor you see Daniel Shiffman using in the video posted by Raphaël, above.)