[gonzaloriestra]

WHY are these changes introduced?

This is the third step of the ESLint-to-Oxlint migration. After establishing native Oxlint parity in CI, this layer makes Oxlint authoritative for migrated rules and leaves ESLint responsible only for compatibility gaps.

WHAT is this pull request doing?

• derive an ESLint disable layer from enabled rules in oxlint.json, avoiding duplicated checks and rule drift
• map Oxlint TypeScript, import, and Node plugin names back to their ESLint equivalents
• retain ESLint checks that Oxlint cannot yet replace, including Nx boundaries, local CLI rules, import ordering, naming conventions, and unsupported JSDoc/TSDoc rules
• label ESLint explicitly as a compatibility check in scripts, CI, and contributor documentation
• run Oxlint fixes before ESLint compatibility fixes
• preserve the full ESLint autofix configuration used to make generated GraphQL output deterministic
• suppress ESLint unused-disable reporting because directives can now target rules owned by Oxlint

How to test your changes?

• pnpm lint:eslint --output-style=static
• pnpm lint
• pnpm graphql-codegen with no generated-file changes
• verified representative ESLint effective config disables Oxlint-owned rules while retaining compatibility rules
• git diff --check

The compatibility-only ESLint pass decreased locally from approximately 19.8 seconds to 16.2 seconds; plugin and parser startup now dominate its remaining runtime.

[gonzaloriestra]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• Remove ESLint and use independent Oxlint rules #8211
• Close remaining Oxlint parity gaps #8210
• Run local CLI rules with Oxlint #8209
• Make Oxlint the primary linter #8208 👈 (View in Graphite)
• Add type-aware Oxlint alongside ESLint #8206
• Decouple Prettier from ESLint #8204
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

This PR seems inactive. If it's still relevant, please add a comment saying so. Otherwise, take no action.
→ If there's no activity within a week, then a bot will automatically close this.
Thanks for helping to improve Shopify's dev tooling and experience.

[github-actions]

Differences in type declarations

We detected differences in the type declarations generated by Typescript for this branch compared to the baseline ('main' branch). Please, review them to ensure they are backward-compatible. Here are some important things to keep in mind:

• Some seemingly private modules might be re-exported through public modules.
• If the branch is behind main you might see odd diffs, rebase main into this branch.

New type declarations

We found no new type declarations in this PR

Existing type declarations

packages/cli-kit/dist/public/node/session.d.ts

@@ -151,15 +151,6 @@ export interface EnsureAuthenticatedBusinessPlatformOptions extends EnsureAuthen
  * @returns The access token for the Business Platform API.
  */
 export declare function ensureAuthenticatedBusinessPlatform(scopes?: BusinessPlatformScope[], options?: EnsureAuthenticatedBusinessPlatformOptions): Promise<string>;
-/**
- * Whether SHOPIFY_SERVICE_ACCOUNT_TOKEN is set, which makes it the automation token the CLI authenticates with.
- *
- * True even when it's empty or set together with another automation token variable. Commands use this to skip logins
- * saved on this machine, and authentication then reports any problem with the variables.
- *
- * @returns True when SHOPIFY_SERVICE_ACCOUNT_TOKEN is set.
- */
-export declare function isServiceAccountTokenSet(): boolean;
 /**
  * Fails when SHOPIFY_SERVICE_ACCOUNT_TOKEN is set, for commands that can't run with that token.
  *