Add more ESLint recommended rules, and enforce them in CI.

[jgerigmeyer]

A replacement of #351. Based off of #372.

A few notes/questions:

1. What is the value of "warnings" vs "errors", and what should cause CI to fail? Right now the default recommended rules are set to "error" (except where overridden), but most of the custom rules are set to "warn". CI will fail if there are any errors or warnings. I'd probably recommend moving all of them to "error" and not using "warn" at all -- it sort of defeats the purpose if warnings pile up unaddressed, and can easily mask newly introduced unintentional warnings.
2. There are a handful of places where rules are enabled globally (e.g. no-cond-assign, no-sparse-arrays, no-redeclare, no-unused-vars) because they're helpful in revealing common typos, but then are overridden in specific instances where the usage is intentional. There are other rules (e.g. no-loss-of-precision) that we might want to disable globally?

Very open to feedback and/or rules changes!

[netlify]

✅ Deploy Preview for colorjs ready!

Name	Link
🔨 Latest commit	aac6e62
🔍 Latest deploy log	https://app.netlify.com/sites/colorjs/deploys/65677bbb20b3a10009f68818
😎 Deploy Preview	https://deploy-preview-367--colorjs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[LeaVerou]

Hey, thank you so much for your hard work and perseverance on this!

1. Regarding errors vs warnings: I tend to specify all linting as warnings, to distinguish from actual errors.

2. As a general philosophy, I am against // eslint-disable-* directives. I think the code should be the source of truth, written in the optimal way, and tools like ESLint should just work with it without leaving traces in the codebase. It should not require more migration to swap ESLint for another linter than migrating the config file itself. If we need to override a rule (rather than refactoring the code) I take it as a strong indication that maybe the rules we have are too strict and we've ended up fighting against them rather than them helping us, so we should not be enforcing the rule in the first place, or we should be enforcing a more lax version of the rule that would allow that kind of formatting.

3. It would be good to commit some of the uncontroversial code changes this PR introduces (e.g. adding semicolons, space between func name and opening paren, things like that) in a separate PR so that this would not be as huge to review. In fact, I'd suggest this workflow:

   1. Take all code changes in here. Remove those that require eslint overrides, and those that clearly do not improve readability.
   2. Send a PR with just the code changes, without the linting infrastructure.
   3. Once we iterate and merge that, then we can focus on any changes the linting infrastructure introduces without being lost in the hundreds of missing semicolons added and the like.
      How does that sound?

[LeaVerou]

I’m a little uncomfortable with leaving coding style up to mystery bags of rules that we have little control over, and don't fully realize what we're enforcing. Could we list the rules explicitly?

[jgerigmeyer]

I'm torn on this. On one hand I understand wanting the rules to be explicit and opt-in; on the other hand ESLint is very stable, and maintains a long list of recommended rules that don't change often and would be duplicated here. And typescript-eslint also disables some of the default ESLint rules that it replaces, so it would be a very long list. I'm open to copying them here if you prefer that (and we could try narrowing them down). The lists this is currently using are:

• https://github.com/eslint/eslint/blob/v8.54.0/packages/js/src/configs/eslint-recommended.js
• https://github.com/typescript-eslint/typescript-eslint/blob/v6.13.1/packages/eslint-plugin/src/configs/eslint-recommended.ts
• https://github.com/typescript-eslint/typescript-eslint/blob/v6.13.1/packages/eslint-plugin/src/configs/recommended.ts
• https://github.com/typescript-eslint/typescript-eslint/blob/v6.13.1/packages/eslint-plugin/src/configs/stylistic.ts

[jgerigmeyer]

Continued in #373

[jgerigmeyer]

1. Take all code changes in here. Remove those that require eslint overrides, and those that clearly do not improve readability.
2. Send a PR with just the code changes, without the linting infrastructure.
3. Once we iterate and merge that, then we can focus on any changes the linting infrastructure introduces without being lost in the hundreds of missing semicolons added and the like.
   How does that sound?

@LeaVerou I pulled out the code changes into #372, and rebased this PR off of that one.