What does an ESLint warning or error tell you?
ESLint points to the location and rule that noticed something. In plain JavaScript, an enabled rule can flag a misspelled name the code never defines. The rule points you to the question to ask. Does the line refer to the wrong name, or did the project omit an expected setting?
JavaScript and TypeScript can have different rules. Check the project’s actual settings before expecting a specific warning.
When should you ask for a report before a fix?
Start with the project’s lint check without automatic fixes. Look at the files and rule names it reports. If you ask an agent to fix a finding, review the changed lines and run the check again. A fixable rule can write changes when the fix option is enabled.
Keep a test for what users should see. A clean rule report cannot tell you whether the app gave the right total or showed the right message.
What do you need to use the same checks on another computer?
ESLint is MIT-licensed and runs with a compatible Node.js version. Keep the project settings, package versions and any rules supplied by plugins with the code. A plugin adds checks or support the core tool does not include. Use trusted project dependencies when running it.
The local tool has no subscription. Running it in a hosted build service may use that service’s time allowance.
How would you check whether a rule catches a typo?
Use a fictional JavaScript file on paper. Do not run a package, open a live app or change the project.
- Pick the exact ruleAssume the undeclared-name rule is enabled. Write a line that defines orderTotal and a second line that reads orderTotl.
- Read the expected reportCircle orderTotl as the undeclared name. Correct the spelling on the paper copy and expect that one finding to clear.
- Verify a different question separatelyWrite the total the customer should see for two fictional items. A lint pass alone would not check that result.