Migrate to oxfmt oxlint

[amitsingh-007]

Check if the Pull Request fulfils these requirements

• Does the extension require a version change?

Greptile Summary

This PR replaces the XO + Prettier toolchain with oxlint and oxfmt (Rust-based linter and formatter) across the entire monorepo. It also upgrades TypeScript from 6.0.3 to 7.0.2 and Next.js from 16.2.10 to 16.3.0-canary.83 (required to support TS7 via experimental.useTypeScriptCli).

• Tooling swap: xo.config.ts, .prettierrc.json, and .prettierignore are removed; .oxlintrc.json and .oxfmtrc.json are added. Pre-commit hooks are updated in .lefthook.yml to run oxlint --fix then oxfmt sequentially (sequential order avoids write races on the same files).
• Source file changes: All 172 changed files contain only import-order reformatting driven by oxfmt's sortImports config — no logic changes were made.
• Next.js canary dependency: 16.3.0-canary.83 is used because experimental.useTypeScriptCli, which requires Next ≥ 16.3, is needed to work around TypeScript 7 dropping the JS compiler API; this is documented in a next.config.ts comment.

Confidence Score: 5/5

Safe to merge — all 172 source file changes are import-order reformatting only, with no logic touched.

The migration is purely additive tooling change. Every source file diff is limited to import ordering; no business logic, auth, data handling, or API contracts changed. The configuration files correctly replicate the rule set from the old XO config.

pnpm-workspace.yaml — the next: 16.3.0-canary.83 entry is worth revisiting once a stable 16.3 ships.

_{Reviews (3): Last reviewed commit: "chore: address PR review — enable sortPa..." | Re-trigger Greptile}

[webext-bot]

Extension version is updated from 24.12.1 to 24.13.0

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (1) 📜 Skill insights (1)

Context used

✅ Compliance rules (platform): 23 rules

✅ Skills: e2e-test-generation

1. Web setup imports from @playwright/test 📜 Skill insight ⚙ Maintainability

Description

apps/web/tests/auth.setup.ts and apps/extension/tests/auth.setup.ts import expect and test
directly from @playwright/test instead of from a project fixture module. This violates the
required E2E test import pattern.

Code

apps/web/tests/auth.setup.ts[6]

+import { chromium, expect, test as setup } from '@playwright/test';

Relevance

⭐⭐ Medium

Repo E2E tests usually import test/expect from local fixtures; no historical enforcement against
@playwright/test imports.

PR-#3822
PR-#3794

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1806019 forbids importing test/expect from @playwright/test, and the cited
setup files explicitly use import { chromium, expect, test as setup } from '@playwright/test';,
demonstrating the non-compliant direct imports.

apps/web/tests/auth.setup.ts[4-7]
apps/extension/tests/auth.setup.ts[3-6]
Skill: e2e-test-generation

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
E2E code must import `test` and `expect` from the project’s fixtures rather than directly from `@playwright/test`.

## Issue Context
Both setup files currently do `import { chromium, expect, test as setup } from '@playwright/test';`. Introduce (or use an existing) fixtures entrypoint that re-exports `test`/`expect`, and update these files to import `test`/`expect` from that fixtures module instead (keeping `chromium` imported directly only if necessary).

## Fix Focus Areas
- apps/web/tests/auth.setup.ts[4-7]
- apps/extension/tests/auth.setup.ts[3-6]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. xo removed from lint 📘 Rule violation ✧ Quality

Description

The root package.json no longer runs XO (lint/lint:ci) and removes xo from devDependencies,
so this change set cannot be validated against XO lint requirements. This violates the requirement
that changes be free of XO lint errors.

Code

package.json[R12-15]

+    "lint": "oxlint --fix",
+    "lint:ci": "oxlint",
+    "format": "oxfmt",
+    "format:check": "oxfmt --check",

Relevance

⭐⭐⭐ High

XO still appears intentionally used (xo.config.ts, lefthook xo); removing XO would likely be pushed
back.

PR-#4063
PR-#3951

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1805908 requires XO lint to be run and pass; the updated package.json replaces XO
with oxlint for lint/lint:ci and no longer includes xo in devDependencies.

Rule 1805908: Code changes must be free of XO lint errors
package.json[7-33]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Compliance requires XO lint to pass, but this PR switches linting from `xo` to `oxlint` and drops XO from tooling.

## Issue Context
If the repo is intentionally migrating away from XO, either the compliance rule/CI expectations must be updated accordingly, or XO must remain available and executed (e.g., as an additional script/CI step) to satisfy the current requirement.

## Fix Focus Areas
- package.json[11-33]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Type-aware TS project undefined 🐞 Bug ☼ Reliability

Description

.oxlintrc.json enables options.typeAware: true while the repo’s root tsconfig.json excludes
apps/ and packages/, and the root pnpm lint runs oxlint from the repo root. This leaves
type-aware linting dependent on implicit tsconfig discovery rather than an explicitly-defined
monorepo TypeScript project, making lint coverage/behavior brittle across workspaces.

Code

.oxlintrc.json[R16-19]

+  "options": {
+    "typeAware": true,
+    "reportUnusedDisableDirectives": "warn"
+  },

Relevance

⭐⭐ Medium

No prior oxlint typeAware/tsconfig evidence; team has accepted robust CWD/monorepo config fixes
before.

PR-#3880
PR-#3788

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR enables type-aware linting and routes pnpm lint through oxlint at repo root, but the
repo-root TS project configuration explicitly excludes all workspace code. This mismatch means
type-aware linting is not anchored to an explicit TS project that includes the linted files across
workspaces.

.oxlintrc.json[16-19]
package.json[7-16]
tsconfig.json[1-5]
apps/web/tsconfig.json[1-17]
apps/extension/tsconfig.json[1-25]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Oxlint is configured to run type-aware, but the repo is a multi-project TS monorepo where the repo-root `tsconfig.json` explicitly excludes the main source trees (`apps/`, `packages/`). Without explicitly defining which TS project(s) oxlint should use for type-aware analysis, lint behavior/coverage depends on implicit discovery and can become inconsistent or break when invoked from the repo root (including in hooks/CI).

### Issue Context
- Root lint command runs from repo root (`pnpm lint` -> `oxlint --fix`).
- Root `tsconfig.json` excludes workspace source directories.
- Each workspace has its own `tsconfig.json`.

### Fix Focus Areas
- .oxlintrc.json[16-19]
- package.json[7-16]
- tsconfig.json[1-5]

### Suggested fix approach
1. Create a dedicated monorepo lint tsconfig (e.g., `tsconfig.oxlint.json`) that includes or references the workspace TS projects (`apps/web`, `apps/extension`, `packages/*`).
2. Configure oxlint to use that tsconfig explicitly (via oxlint config option or CLI flag) when `typeAware` is enabled.
3. Alternatively, if explicit project selection is not supported, scope `typeAware` to overrides per workspace and ensure each override is executed with the workspace’s `tsconfig.json`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---