chore: Migrate to ESLint flat configuration

[sdrozdsap]

Migrate to ESLint flat configuration

This PR migrates from the old .eslintrc.json format to the new ESLint flat config (eslint.config.mjs). The old format is deprecated and will eventually stop being supported, so this is something we needed to do sooner or later.

Some ESLint-related packages were updated and redundant sub-packages removed since they're now bundled.

Issues found along the way

After the migration, linting started failing for 7 projects: storefrontlib, core, order, opf, cpq-quote, setup, and storefrontapp. After investigating each failure, here's what was going on:

no-console was silently broken before. Turns out the old config had a bug where legacy-ng-cli-compat.json was quietly overriding our strict no-console: "error" with a broad allow list that included "log". So console.log was effectively allowed everywhere, even though it wasn't supposed to be. The flat config now correctly enforces the intended behaviour. I removed a few leftover debug console.logs from spec files and added eslint-disable where console usage is intentional (test assertions like expect(console.warn), a mock logger, and the build-time env log in storefrontapp/esbuild/plugins.ts).

Nx workspace rule names changed format. In the old config rules were named like @nx/workspace/rule-name, but flat config registers them as @nx/workspace-rule-name (with a dash). Some eslint-disable comments in core referenced the old names, so those were updated.
For details see

• Bug: Nested rule names don't work with flat config eslint/eslint#17857
• fix(linter): fix workspace-rule naming with flat config nrwl/nx#20782

A bunch of eslint-disable comments became unnecessary. Rules like max-len, no-bitwise, import/no-deprecated etc. are no longer active in the new config, so their disable directives were just noise. Cleaned those up

Also deleted tools/eslint-plugins/legacy-ng-cli-compat.json and legacy-ng-cli-compat--formatting-add-on.json. I couldn't find any reason to keep them around.

QA

ci-scripts/validate-lint.sh

Also you can manually break some linting rule and check if your IDE highlights it

[github-actions]

Merge Checks Failed

Please push a commit to re-trigger the build.
To push an empty commit you can use `git commit --allow-empty -m "Trigger Build"`

[cypress]

spartacus    Run #52644

Run Properties:   Passed #52644  •  478dc88b3b ℹ️: Merge ebb15ccdf8b0d6635c74367ab73128c755a571a0 into 96062566bce7cf1b0a2140790069...

Project	spartacus
Branch Review	chore/migrate-eslint-flat-config
Run status	Passed #52644
Run duration	04m 27s
Commit	478dc88b3b ℹ️: Merge ebb15ccdf8b0d6635c74367ab73128c755a571a0 into 96062566bce7cf1b0a2140790069...
Committer	sdrozdsap
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	3
Pending	0
Skipped	0
Passing	101
View all changes introduced in this branch ↗︎

[github-actions]

Merge Checks Failed

Please push a commit to re-trigger the build.
To push an empty commit you can use `git commit --allow-empty -m "Trigger Build"`

[github-actions]

Merge Checks Failed

Please push a commit to re-trigger the build.
To push an empty commit you can use `git commit --allow-empty -m "Trigger Build"`

[pawelfras]

Nitpick: Let's update comments in our custom eslint rules to point to the proper rule name, e.g:

- NOTE: The rule will be available in ESLint configs as "@nrwl/nx/workspace/no-ngrx-fail-action-without-error-action-implementation"
+ NOTE: The rule will be available in ESLint configs as "@/nx/workspace-no-ngrx-fail-action-without-error-action-implementation"

Also, let's remember to inform tribe about the change and required "eslint.useFlatConfig": true in VSC config

[pawelfras]

query: is this a recommended way of using our custom rules? I couldn't find it in the official Nx docs: https://nx.dev/docs/technologies/eslint/guides/custom-workspace-rules

[sdrozdsap]

To be honest, I'm not sure if its recommended or not. I think this is similar to what we had before, and I didn't give much thought about how we can refactor or change it. This approach is tested and works, but if you see any issue with it Im open minded for the change

[sdrozdsap]

@pawelfras about that:

Also, let's remember to inform tribe about the change and required "eslint.useFlatConfig": true in VSC config

I actually don't have "eslint.useFlatConfig": true and it still works since flat config is the default now. Doesn't it work without it in your case?

[pawelfras]

@pawelfras about that:

Also, let's remember to inform tribe about the change and required "eslint.useFlatConfig": true in VSC config

I actually don't have "eslint.useFlatConfig": true and it still works since flat config is the default now. Doesn't it work without it in your case?
I was referring to the information ESLint extension setting:

Only now I realised we have ESLint version > 9.0.0, so the config is set to true by default. Indeed, it works without setting it explicitly to true. Thanks!