docs: track bun lint compatibility until a stable release

[amondnet]

Summary

Adds docs/research/bun-lint-compatibility.md. It tracks how @pleaseai/eslint-config behaves under Bun's built-in bun lint until bun lint ships in a stable Bun release.

• Baseline from canary 1.4.4-canary.1+5f5799ed1: 103 / 253 native / JS rules as-is, and 129 / 227 with ts → @typescript-eslint. Results match ESLint, with no speedup at this repo's size.
• Findings: only part of eslint-plugin-n runs natively (none of antfu's 8 node/* rules); after the rename, existing ts/… disable comments become errors; a package.json lint script shadows the built-in; and --doctor wrongly suggests removing @pleaseai/eslint-config.
• A watch list (stable release, --no-script, native JSON/Markdown, bun lint: overrides[].files extglob patterns silently never match with an oxlint config, but match with an ESLint config oven-sh/bun#45470, TypeScript 7 vs. typescript-eslint) and a manual re-check procedure.

Docs only. No package or config changes.

Related issue

Refs #56 (summary posted in #56 (comment))

Checklist

• PR title follows Conventional Commits
• Packages build (bun run build)
• Lint/format pass (bun run lint)
• Documentation updated if behavior changed
• No breaking change, or a BREAKING CHANGE: note is included

---

Summary by cubic

Adds docs/research/bun-lint-compatibility.md, tracking how @pleaseai/eslint-config behaves under Bun's canary bun lint until it ships in a stable release, plus comparison baselines for @antfu/eslint-config 9.5.1 and eslint-config-xo 6.0.0. Baseline from 1.4.4-canary.1+5f5799ed1: 103/253 native rules as-is, 129/227 after renaming ts → @typescript-eslint, matching ESLint results with no speedup at this repo size. Re-measured on the oven-sh/bun#45595 PR build, which adds native JSON and Markdown rules.

Findings

• Only part of eslint-plugin-n runs natively; none of antfu's 8 enabled node/* rules do.
• After the ts rename, existing eslint-disable ts/... comments become errors.
• A package.json lint script shadows the built-in; --no-script is documented but missing from the tested canary.
• --doctor wrongly suggests removing @pleaseai/eslint-config even though eslint.config.ts imports it.
• eslint-config-xo silently misses 16 findings on a whole project because Bun gives types only to native rules.
• With #45595, Markdown rules run natively for antfu-based configs; JSON still goes to ESLint because antfu uses eslint-plugin-jsonc.
• Includes a watch list and a manual re-check procedure to run against future stable releases.

^{Written for commit f18ddc4. Summary will update on new commits.}

[cloudflare-workers-and-pages]

Deploying code-style with    Cloudflare Pages

Latest commit:	f18ddc4
Status:	✅  Deploy successful!
Preview URL:	https://373cef6a.code-style.pages.dev
Branch Preview URL:	https://docs-56-bun-lint-compatibili.code-style.pages.dev

View logs

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[gemini-code-assist]

Code Review

This pull request introduces a new documentation file, docs/research/bun-lint-compatibility.md, to track the compatibility of @pleaseai/eslint-config with Bun's built-in bun lint command. The documentation details current benchmark results, findings, a watch list, and a re-check procedure. Feedback on the pull request suggests improving the re-check bash script by parameterizing the platform architecture instead of hardcoding Linux-specific values, ensuring better usability for developers on macOS or other systems.

[gemini-code-assist]

[MEDIUM] Hardcoded Linux-specific platform in re-check procedure

Problem: The re-check procedure hardcodes the Linux x64 binary (bun-linux-x64.zip and the bun-linux-x64 directory), which will fail for developers running macOS or other architectures.
Rationale: This style guide (Section 1 - Maintainability: Can future engineers read and modify it easily?).
Suggestion: Define a PLATFORM variable at the beginning of the script block to make it easy for developers on macOS or other platforms to adjust the target binary.

Suggested change

	gh release download canary -R oven-sh/bun -p 'bun-linux-x64.zip' --clobber
	unzip -oq bun-linux-x64.zip
	B=/tmp/bun-canary/bun-linux-x64/bun
	PLATFORM="linux-x64" # Change to "darwin-aarch64" or "darwin-x64" if on macOS
	gh release download canary -R oven-sh/bun -p "bun-${PLATFORM}.zip" --clobber
	unzip -oq "bun-${PLATFORM}.zip"
	B="/tmp/bun-canary/bun-${PLATFORM}/bun"

References

1. Section 1 - Maintainability: Can future engineers read and modify it easily? ^(link)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud