[Jarred-Sumner]

What does this PR do?

Follow-up to #44805. That PR made bun lint and bun format (now bun fmt) match ESLint, oxlint, Prettier and oxfmt for people who migrate. This one is for someone who has none of those and types bun lint for the first time.

With an ESLint, oxlint, Prettier or oxfmt config, what changes moves toward the tool itself: findings come in oxlint's order, files that oxlint accepts are no longer refused, and a Prettier config that names prettier-plugin-tailwindcss is formatted and not refused. The exceptions are a few outputs of Prettier and oxfmt that change what a file means, which Bun no longer copies. Each is listed below.

It also moves the host for JavaScript plugins (third-party ESLint rules) from JavaScript to native code, and runs it on the thread that lints the file. See "JavaScript plugins" below.

It fixes bugs that #44805 put on main, two of which rewrite files they shouldn't. See "Bugs in #44805".

bun format is now bun fmt

The formatter's subcommand is bun fmt, like cargo fmt, go fmt, deno fmt and zig fmt. Its section in bunfig.toml is [fmt] ([fmt.sortImports], [[fmt.overrides]]). Neither name has been in a release.

• Most projects already have a "format" script. A script with the command's name wins over the command, so bun format ran Prettier until the script was changed. bun fmt is the formatter from the first run.
• bun format is no longer a command. It runs the project's format script, as it did before. Without one it says Script not found "format" and note: The formatter is bun fmt.
• A [format] section in bunfig.toml is refused (Unknown section [format], Did you mean [fmt]?), not ignored.
• What wins over the command is now called fmt: a fmt script (with prefmt and postfmt), fmt.ts, fmt/index.js, node_modules/.bin/fmt. Inside a fmt script, bun fmt is the formatter.
• Unchanged: the --format flag of bun lint and bun fmt, format = ".." under [lint], the rule bun/format, and the docs URLs.

Prettier plugins that are built in

bun fmt doesn't load Prettier plugins, and it refused every file of a project whose .prettierrc named one it didn't know. That included prettier-plugin-tailwindcss, the most used plugin there is (10 M downloads a week), although Bun has had a native port of it since #44805. It could only be turned on from bunfig.toml.

• prettier-plugin-tailwindcss in a Prettier config now just works. Leave it in plugins.
  • However it's named: the bare name, a path or file: URL into node_modules, a URL, the imported module object, in overrides, with --plugin, in package.json, in a shared config. plugins: [] in an override turns it off.
  • All eight options (tailwindConfig, tailwindStylesheet, tailwindEntryPoint, tailwindFunctions, tailwindAttributes, tailwindPreserveWhitespace, tailwindPreserveDuplicates, tailwindPackageName), with the plugin's defaults, its rule for relative paths, and its error for a value of the wrong type.
  • The plugin's own rules for JavaScript (nested calls, member chains, /regex/ names), which differ from oxfmt's.
  • When tailwindcss isn't installed, or is version 4 with a JavaScript tailwindConfig, or version 3 with a style sheet, the real plugin uses a Tailwind it bundles. Bun then asks the installed plugin's documented sorter entry for the order of the classes. Nothing is ever downloaded.
  • MDX, <DIV CLASS="…"> and LWC files are sorted too.
• Another plugin next to it is still refused, and only that one is named.
• "All matched files use Prettier code style!" is no longer printed above "1 file was not formatted".
• @prettier/plugin-oxc is accepted. It only swaps the parser: real Prettier prints 3,939 files byte for byte the same with and without it. Its order relative to the Tailwind plugin in plugins matters in Prettier, and does here.
• prettier-plugin-packagejson: files named package.json go to the installed Prettier, like .svelte files with the Svelte plugin, and everything else is formatted natively. Before, every file of the project was refused. Bun's sortPackageJson isn't used for it, because it's oxfmt's order and not the plugin's: 28 of 50 made-up files come out different.
• The warning names the plugins that have no effect, not plugins as a whole.

plugin in .prettierrc	downloads a week	what happens
prettier-plugin-tailwindcss	9.95 M	built in (new)
@trivago/prettier-plugin-sort-imports, @ianvs/…, prettier-plugin-organize-imports	5.9 M	built in
@prettier/plugin-oxc	0.28 M	built in (new)
prettier-plugin-packagejson	1.23 M	its files go to the installed Prettier (new)
prettier-plugin-svelte, -astro, @prettier/plugin-xml, -sh, -sql, -toml, -java, …	5.5 M	their files go to the installed Prettier
any other (-jsdoc, -sort-json, -css-order, …)		the files it applies to are refused, and it's named

prettier-plugin-jsdoc stays refused on purpose. Bun's jsdoc option follows oxfmt's, which is a rewrite of the plugin: on 251 real files with 3,222 JSDoc comments, 26 files differ from the plugin's output.

Compared with Prettier 3.9.9, the plugin 0.8.1, and Tailwind 4.3.3 and 3.4.19: 13,654 of 13,952 JavaScript and TypeScript files are byte-equal (57 contexts, 32 expressions, 4 sets of options), 2,148 of 2,176 files in HTML, Vue, Angular, LWC, Handlebars, CSS, SCSS, Less, Markdown and MDX, and all 15 Tailwind 3 projects (custom themes, prefix, important, separator, @apply). About half of the differences are the one below. The rest: a directive inside a function inside cn(…) in TypeScript, and Vue or Angular bindings that don't parse.

One deliberate difference. The real plugin trims a class string that touches other text, which joins two classes: className={`header${open ? " active" : ""}`} becomes `header${open ? "active" : ""}`, so the element gets headeractive. It happens in .ts, .tsx, .jsx and Vue. Bun keeps that blank.

Formatting that changed what a file means

#44805 re-parsed every file after formatting it and compared the trees. That cost up to 21% of a run, and on 10,100 real files it refused none. It's off by default now, and --debug-check turns it on, like Prettier's flag of that name.

The only inputs it ever caught were ones where Prettier's or oxfmt's own output means something else and Bun printed the same bytes. So the printers are fixed instead. Each row is in test/cli/format, with the tool's output next to Bun's:

input	Prettier 3.9.9 / oxfmt 0.72	now
font-family: Font\ Awesome	Font\Awesome (\A is a hex escape)	kept
b: d\ ;, @extend .a\ ;, f(a\ , b)	the backslash escapes the next character	kept
x |b in a selector	x|b: a descendant becomes a namespace	kept
a ? b : c; then (d ? e : f) ? g : h; with --no-semi --experimental-ternaries	no ; before the (: one call	;(
a < b > c in TypeScript, broken after the >	reads as a<b>; c	doesn't break there
<!DOCTYPE html>, <textarea>, <pre>, a <script> with // a in Handlebars	dropped or joined	kept
{{a.[]}}, {{[a/b]}}, {{~! b ~}} in Handlebars	another path, another comment	kept
a comment inside a TOML inline table	the rest of the table is commented out	one entry per line
YAML >+ with --prose-wrap=never, ? |+ as a key, --- ---, a key over two lines in a flow map	the value changes, or the output doesn't parse	the same value
{{concat "p-4 flex " x}} with Tailwind sorting	the class joins the value of x	kept
a file that is nothing but no-break spaces	emptied	kept

• It costs no parity on real code: both upstream suites pass with their expected files untouched. On 14,835 small style sheets 51 differ from Prettier, and all 51 have a backslash right before white space.
• --debug-check for Handlebars compares the two parsed trees (it only read the printer's own flag), and with Tailwind sorting on it compares the text that would be written.
• bun fmt no longer builds the data for the check for every JavaScript and TypeScript file when the flag isn't given.
• Known and left: 13 Markdown inputs with emphasis nested three deep, and 67 upstream YAML inputs of one kind (blank lines at the end of a block scalar that are indented deeper than it), where the upstream snapshots record the loss.

What was wrong

Found by using the merged build on a fresh project, and from the first bug reports:

• With only bunfig.toml, 572 of the built-in rules could not be turned on (Could not find plugin "unicorn" in configuration.). Any @typescript-eslint/* rule set to warn or error killed the whole run if the project had a single .js file.
• A typo in [lint.rules] or --rule was ignored silently.
• bun lint --init wrote an .oxlintrc.json with a $schema pointing into node_modules/oxlint, didn't say which file it wrote, and switched the project to oxlint's rules and output.
• A .tsx file with a conditional hook, a list without key and a stale effect dependency got no report, even though the rules are built in.
• Nearly everything was an error, including prefer-const, no-explicit-any in a .d.ts, and dead stores. no-useless-assignment was reported as a bug because its message doesn't say why.
• Default output was ESLint's stylish: absolute paths, no code.
• Import sorting and Tailwind class sorting could not be turned on from bunfig.toml.
• --help was 84 lines. Messages and docs were hard to read.
• No --staged, nothing to tell someone migrating what runs natively.
• A fresh bun init project failed bun lint and bun fmt --check.

With no config file

• Every built-in rule can be named in [lint.rules], --rule and comments, under either spelling (@typescript-eslint/x or typescript/x). No plugins to list
• Rules ported from oxlint take their options
• [lint.settings]
• [[lint.overrides]]
• An unknown rule is an error with a suggestion
• A mistake in [lint.rules] gets a code frame of bunfig.toml and a plain message
• React: rules-of-hooks, jsx-key and exhaustive-deps are on if react is in package.json
• Likely bugs are errors. Unused or dead code and suggestions are warnings
• .d.ts files only get the rules that are errors
• pretty is the default output, with a summary line
• 49 hints under reports whose message alone is puzzling: It is overwritten on line 5 and line 12 before it is read., The return on line 4 can end the render before it is called., Did you mean ===?
• bun fmt --check uses Bun's wording, not Prettier's
• [fmt]: sortImports, sortTailwindcss, sortPackageJson, jsdoc, [[fmt.overrides]]
• sortImports also sorts names in { } and merges duplicate imports
• TOML is formatted by default. A multi-line inline table keeps one entry per line, ["warn", { .. }] stays hugged, and a one-line table never gets a line break (TOML 1.0 parsers reject those)
• bun fmt skips *.min.js, *.min.css and lock files. A file named on the command line is still formatted
• _unused names are ignored by no-unused-vars
• A core rule and its typescript-eslint version act as one rule (26 pairs). Setting either name sets both, and a problem is never reported twice
• A type-aware rule runs as soon as you turn it on in [lint.rules]. typeAware = true adds the recommended set
• --deny-warnings, --silent and -A/-W/-D work on Bun's defaults. They used to switch the run to oxlint's rules, so --deny-warnings made a failing lint pass
• The hooks rules also cover files without JSX (useThing.ts)
• A disable comment for a rule that is off is left alone

Default rules

Every rule that's on by default was tried on ordinary code: seven made-up projects (an API server, a React app, a CLI, a library, a monorepo, a folder of generated and vendored files, a collection of idioms) and the four bun init templates. What got reported on code that works was turned down, narrowed or fixed. For each change, the bug the rule exists for was tried too and is still reported. All of this only applies with no ESLint or oxlint config.

Rule	Before	After	Why
@typescript-eslint/no-require-imports	error	off	Bun runs require() and import in one file. tailwind.config.ts and React Native's <Image source={require(..)}> have no alternative
@typescript-eslint/ban-ts-comment	error	warn	// @ts-ignore is written on purpose
no-cond-assign	error	warn	while (m = re.exec(s))
no-prototype-builtins	error	warn	obj.hasOwnProperty(k) works
no-ex-assign	error	warn	err = err instanceof Error ? err : new Error(String(err))
no-control-regex	error	warn	ANSI escape patterns
@typescript-eslint/no-wrapper-object-types, no-unsafe-function-type	error	warn	target: Object, cb: Function
@typescript-eslint/no-unsafe-declaration-merging	error	warn	interface Bus + class Bus extends EventEmitter
@typescript-eslint/no-non-null-asserted-optional-chain	error	warn	map.get("a")?.v!
@typescript-eslint/no-duplicate-enum-values	error	warn	enum Level { Off = 0, None = 0 }
bun:test/no-export	error	warn	export const fixture in a test file
no-unsafe-assignment, -call, -member-access, -return, -argument (--type-aware)	error	warn	About 25 of 30 errors in an ordinary API project
no-loss-of-precision	error on everything	error on integers	A 64-bit id is a bug, 3.14159265358979323846 isn't
no-irregular-whitespace	error everywhere	error in code	French and Japanese text in strings, comments and JSX
no-unused-expressions	warn on cb && cb()	quiet	It does something
@typescript-eslint/no-misused-promises	error on <form onSubmit={asyncFn}>	quiet	How React code handles events
@typescript-eslint/no-namespace	warn inside declare global	quiet	There's no other way to write it
no-empty-pattern	warn on async ({}, use) =>	quiet	Playwright requires the {}
no-fallthrough	error after process.exit()	process.exit() and process.abort() end a case. With types, so does a call that returns never	CLI code. fall-through, fallthrough and no break comments count too
react-hooks/rules-of-hooks	error on Playwright's use and Storybook's render	quiet	use is a parameter there, and Storybook renders render as a component
react/jsx-key	error on every array of elements	only where React renders the array	steps[step], icon tables, actions={[..]}
no-constant-binary-expression	error on {false && <X />}	quiet for true, false, 0, 1	Switching a block off
no-undef	error on a name tested with typeof	quiet	The author knows it may be missing
no-unused-vars	React and h reported in files with JSX	counted as used	Removing the import breaks the classic runtime
/* eslint-env */	fatal error	honored	Old JavaScript files are full of them

• Three options only Bun has, so the old behavior is one line away: react/jsx-key checkArraysOutsideJSX, no-constant-binary-expression allowLiteralToggle, no-loss-of-precision ignoreDecimals. Under an ESLint config they're rejected with ESLint's own error
• Bun's default options stay when you only set a severity: "no-unused-expressions" = "error" keeps allowShortCircuit. --rules -f json and the docs show them as the defaults
• Every global of Bun is known, and the globals of service workers
• describe, it, expect, jest, vi, cy and friends are known in *.test.*, *.spec.*, *.e2e.*, *.cy.*, in set-up files like jest.setup.ts and setupTests.ts, and in the project's __tests__, __mocks__, test, tests, spec, e2e and cypress folders
• An untouched bun init --react has 0 problems under bun lint --type-aware. It had 5 errors

On the five code projects, every error that's left is a bug that was planted there. On the folder of generated and vendored files, 309 errors became 9.

--fix-suggestions

The flag applies every suggestion with nobody looking, so with no config it now only applies the ones that can't change code that works. The rest need --fix-dangerously. -f json still lists them all, and nothing changes under an ESLint or oxlint config.

Rule	What its suggestion did to working code
no-unused-vars	Deleted const sent = sendEmail(user);. Dropped the unused next of an Express error handler, which Express recognizes by fn.length === 4
no-unused-private-class-members	Deleted #x = sideEffect();
no-explicit-any	any became unknown: type errors
react-hooks/exhaustive-deps	[ms] became [cb, ms]: the effect runs at other times
require-await	Dropped async: callers get T, not Promise<T>
await-thenable	await null; became null;
no-array-delete	delete list[0] became list.splice(0, 1), which shifts every later item
ban-ts-comment	@ts-ignore became @ts-expect-error: a type error wherever the next line is fine
no-empty-object-type	interface Empty {} became type Empty = object
no-non-null-asserted-optional-chain	Dropped the !
no-case-declarations	Wrapped the case in { }: a later case that uses the let breaks
no-floating-promises	Wrote void save();: "Fixed 1 problem" with nothing fixed

The first two aren't offered at all when they'd delete code that runs. Unused imports still go, with their statement if nothing else is imported, as in ESLint and oxlint. A declaration or a disable comment that's removed takes its line with it, so bun fmt --check passes afterwards.

Bugs in #44805

These are on main today.

• echo "# hi" | bun fmt --parser markdown ignored stdin and rewrote every file in the directory as markdown. Without paths, --parser now formats stdin like Prettier and never touches a file. With real Prettier 3.9.9 as the judge: 252 of 288 parser cases, 108 of 114 flag and config cases and 26 of 31 plugin cases are the same in stdout, stderr, exit code and touched files. None of the rest is about stdin (positions of some syntax errors, oxc parsers that Bun has built in). On main, 280 of the 288 differ
• --parser x with a directory is refused with no config or an oxfmt config, with a glob to use instead. Under a Prettier config it reads every file with that parser, like Prettier (the same 39 of 45 files in a mixed project)
• bun --help format and bun -h format formatted the directory. They print help
• bun --check format a.js rewrote the file and exited 0. Flags of lint and format that stand before the command were dropped. They count now, as for bun --bail test
• bun fmt no longer re-parses what it has formatted. Add bun lint and bun format #44805 compared the syntax tree of every formatted file with the original and refused to write on a difference. On 10,100 real files that change it refused none, the only refusals were inputs where Prettier itself loses something, and it cost up to 21% of a run. It is --debug-check now, as in Prettier. --verify, --no-verify and the verify key in bunfig.toml are gone
• A plugin that throws something odd (Object.create(null), an object with a throwing message getter, after node.loc = null) aborted the process. 345 combinations of where and what: no abort, and the exit code is the real tool's except where Bun doesn't run a custom parser
• An eslint.config.mjs with a top-level await that never settles made bun lint spin forever. It's an error now
• A rule with both create and createOnce ran through createOnce under an ESLint config. ESLint calls create
• Under an oxlint config, --type-aware --type-check reported no type errors once an import/* rule was on (70 errors in real oxlint, 0 in Bun, exit 0). 22 of 28 scenarios differed from oxlint 1.87, now 0
• Under an oxlint config: -A, -W and -D didn't override rules from extends, --fix-suggestions dropped the safe fixes of JS plugins, globals: { x: "off" } hid a global of the env, no-implied-eval had the wrong severity, NaN == NaN was reported once, and invalid values for settings.react.version and no-unused-vars were accepted. All now equal oxlint 1.87
• Under an oxlint config, plugins see oxlint's sourceType, parserOptions.ecmaFeatures and strict mode per file. With 199 rules on 31,379 files, Bun reports 95.13% of what oxlint 1.87 reports, up from 90.44%, and what only Bun reports went from 1,107 to 173. No rule got worse in either direction. What's left is nearly all one thing: a script has no module scope in oxlint
• bun fmt --doctor said "You can remove: prettier" while files were skipped because of a Prettier plugin
• A folder named package.json, .prettierrc or prettier.config.js anywhere in a project made bun fmt give up on the whole run ("Cannot read the configuration file ...: EISDIR", exit 2). Prettier skips such folders, and so did bun lint
• bun -c format and bun -l format rewrote files and exited 0: short flags before the command were dropped. bun -c=other.toml lint is still Bun's own --config
• bun --config=other.toml lint: a mistake in [lint.rules] was shown with a code frame from bunfig.toml
• --staged and --changed dropped files that were named through a symlinked path
• bun lint --fix and bun fmt could write a file twice when two paths lead to it (a link, or another letter case on Windows). A run writes each real file once
• Under an oxlint config, the error for a JavaScript rule that throws vanished when a rule about several files (import/no-cycle) was on too: Bun printed the cycle warnings and exited 0, where oxlint exits 1
• In a .cjs file under an oxlint config, a plugin that called markVariableAsUsed("first") silenced no-unused-vars for the next variable instead
• A package.json, tsconfig.json or rule option nested tens of thousands of levels deep overflowed the stack

Like oxlint, under an .oxlintrc.json

Compared with oxlint 1.87:

	Before	After
127,614 small files: same verdict, and every error identical in words, labels and help	82,600 of the first 88,086	all 127,614
Files Bun refuses and oxlint accepts	112	0
Files Bun accepts and oxlint refuses	92	0
4,703 rows of syntax errors in lint.test.ts		0 differ; 17 more are listed as known, and both tools refuse all 17
oxlint's own test cases with several messages, in its exact order	634 of 713	713 of 713
7,828 findings in real files, in oxlint's relative order	88.9%	all but 1
…and at exactly oxlint's place	37.1%	all but 4

• Findings are printed in the order in which oxlint runs its rules, not by position: node by node as oxc visits them, then rule by rule. It costs nothing: with every category on, 62,000 findings in 220 files take 0.1% fewer instructions than on main, which printed them in another order.
• A file has two scope analyses, as in oxlint. oxlint's own rules see oxc's scopes. JavaScript plugins, and native rules that oxlint doesn't have, see typescript-eslint's. One shared analysis gave false positives in oxlint's own rules as soon as any plugin was on (13 of 87 files). The second one is built on first use: a plugin that never asks about scopes pays nothing, one that walks every scope pays 2.2%.
• Scope::references is in the order in which typescript-eslint's scope manager makes them (compared on 20,000 random programs). That fixed two of Bun's own rules, no-unnecessary-parameter-property-assignment and react/hook-use-state, which differed from ESLint in 16 of 27 and 16 of 23 files.
• Variable, a view that is ESLint's Variable one for one, for ported rules. Eleven rules use it, and three private copies are gone.
• When a rule throws, the file keeps the findings of oxlint's own rules and loses those of every plugin rule, as in oxlint (21 cases). A native rule that oxlint lacks counts as a plugin rule.
• oxc reads a file that can be a script or a module as a script first. If it turns out a module, oxc goes back to each statement where await was a name, and forgets every parser error since. About 50 kinds of error are accepted by oxlint that way, and now by Bun.
• --fix: of two fixes with the same range, the rule that oxlint runs first wins, and what is left is printed in oxlint's order.
• markVariableAsUsed from a plugin doesn't silence oxlint's own no-unused-vars. It doesn't in oxlint either. Two tests that said otherwise had been recorded from Bun.
• A key written twice in a rule's options, settings, globals or env is there once, at its first place, with its last value. A YAML .eslintrc with one is refused, as in ESLint 8.57.1.
• A file that oxc's parser or its scope pass refuses is refused, with every error of the file, in oxlint's order, with its TS(nnnn) code, labels and help: redeclarations, duplicate and undefined exports, reserved words, assignment targets, TypeScript's grammar errors, await and yield where they can't be, private names outside a class
• 89 of 109 common syntax errors (f(a b), x = ;, if (a {}) have oxlint's exact words, up from 4
• A file's findings are printed in oxlint's three groups: built-in rules by place, JavaScript plugins' in the order reported, then every unused disable directive
• Unused bare eslint-disable comments under the default config: 821 differing files, now 0. With the jsdoc or vue plugin on: 334, now 0
• Config files: the last of two duplicate keys wins (22 of 22 cases, was 7), # comments and a #! line are accepted, options for a rule that takes none are refused
• JavaScript plugins see Program start at the first token, and the scopes of oxc's source type: a script has only global, CommonJS has global and a function scope with arguments
• cx.throw(node, "Error", message) lets a native rule fail the way a JavaScript rule does when it throws
• None of it costs a file without such an error more than a few bit tests: bun lint under {} on 9,384 real files runs 4,004 M instructions, against 4,006 M before

Deliberately not copied from oxlint:

	oxlint 1.87	Bun
--fix with 33 or more messages	an unstable sort shuffles the findings that have no fix (lines 21, 3, 4, …, 20, 2)	run order
await; await (x); export {}; and the like	accepted; the rules run on a tree with dummy nodes ('' is not defined at 1:1), and it panics with a JavaScript plugin	accepted; await is a name there
declare function ();	func-names reports it	silent; tsc rejects the code
two call-signature literals in a union, typescript/prefer-function-type	reports each twice	once
several ungrouped accessor pairs in one class, grouped-accessor-pairs	in the order of a hash table	by place
17 shapes that both tools refuse		other words, or one line fewer

Known and not yet matched: when an overrides entry matches a file, oxlint runs its rules in another order. It rebuilds the rule list through an FxHashMap and collects it without a sort (Config::apply_overrides), so the rules run in the table's order, which also differs between x64 and arm64. Bun keeps rule-number order there. Only the order of a file's findings differs, never which are reported. On 60 open-source projects with every category on, 15,951 files have findings: 8,256 are in oxlint's exact order (7,870 before this PR's last rounds), and 1,542 of the 1,941 that have the same lines in another order are in projects with overrides.

Copied although it's worse for users, as on main: import/no-duplicates reports a duplicate only if the two specifiers are neighbors in oxlint's hash table. In a file with 56 duplicates it reports one. And jest/no-identical-title imitates an unstable sort above 20 calls with one title.

The same output on every CPU

An arm64 CI lane found that one rule reported a finding on x64 and nothing on arm64. Rust's hashbrown looks at 16 slots at a time with SSE2 and 8 with NEON, so a table's iteration order differs between the two once it's crowded.

• Bun's emulation of oxc's tables had been made to follow the CPU it was compiled for. It's a constant again.
• Eight places iterated a real hash table on a path to the output. The worst: when .oxlintrc.json has extends, which setting of a rule wins followed the table. Also the names in exhaustive-deps' message, and the order of findings of four rules. All go through the one emulation or a sort now. It was compared with the real table on 60,000 random sequences: 0 differ, and with a width of 8 as a control 18,400 do.
• #![deny(clippy::iter_over_hash_type)] in the ten lint crates.

Faster

CI's LTO builds, main at the merge base against this branch, user instructions, 13,600 real files:

	main	this branch
bun lint, oxlint config, every category on, -f unix	698 M	697 M	-0.14%
the same, default format	705 M	701 M	-0.61%
bun lint, .oxlintrc.json with {}	3,955 M	3,868 M	-2.21%
bun lint, ESLint config with 5 rules	1,596 M	1,576 M	-1.19%
bun lint, no config	5,109 M	5,026 M	-1.62%
…in test/js/node/test/parallel	773 M	764 M	-1.20%
…in test/bundler	469 M	456 M	-2.76%
…in src/js	315 M	314 M	-0.33%
…in test/js/bun	1,058 M	1,047 M	-1.11%
…in test/cli	961 M	934 M	-2.84%
bun check, 220 files	3,949 M	3,933 M	-0.43%
bun fmt --check, 4 folders	3,837 M	3,824 M	-0.33%

• bun lint with no config was 1.7% slower than main, up to 5.5% in a folder of small files. None of it was in a rule. The built-in config had grown from 5 to 10 patterns, so every file cost 20 object tests and 16 pattern tests. Now an extension that no pattern can match (.md, .snap, .css) returns at once, a .js file doesn't ask the **/*.ts objects, and a pattern that ends in /** is asked once per directory. This helps every ESLint-style config.

• Threads merged the same set of config objects in parallel, each sorting 1,600 global names twice, and every set was merged with and without the React rules. Each set is merged once, and the lists of globals are shared.

• -f unix spent 610 instructions per line. It computed where a finding ends, which it doesn't print, and searched the line table for a line it already had. About a third of that now.

• The default format linted a whole file again with every rule to get the help of one problem it shows, and hashed each rule's name for each finding.

• A disable comment walked the whole list of rules for every rule it names.

• bun check: to sort a file's diagnostics, every comparison looked up and converted both files' paths, about 360 instructions, though nearly all pairs are from one file. 23 M of 4,000 M on 220 files with 12,600 errors. The output is byte-identical.

• The possible Jest calls of a test file are sorted as plain keys, without a call per comparison: 17 M of 1,077 M on a folder of test files.

• bun lint -f json is 27% faster with 989 rules on 4,147 files (10.89G instructions to 7.96G), and 34% faster under an ESLint config with 218 rules (1,103M to 724M). For every file and every enabled rule, the list of deprecated rules in use allocated the rule's name and searched a table before it looked at the flag that says whether the rule is deprecated at all. The output is byte for byte the same

• Finding the line starts of a file was 2% of a bun lint run. It is a Highway kernel now: 64 bytes at a time instead of 8

• JavaScript plugins: see below

• Bun.Glob: see below

New

• --init adds [lint] / [fmt] to bunfig.toml
• bun lint --explain <rule> prints the rule's page in the terminal. --rules groups by plugin with descriptions. --rules -f json has IDs, aliases, descriptions and defaults.
• Rule names are clickable links in a terminal
• bun lint --doctor, bun fmt --doctor: what runs natively, what runs in JavaScript, which packages can go
• A short --help. --help --all shows everything, grouped
• A fresh bun init project passes bun lint and bun fmt --check, in all four templates
• --staged, --changed[=<ref>]
• With both an ESLint and an oxlint config, oxlint's is used, with a note. Same for oxfmt over Prettier
• Bun's own messages in plain English

Docs

• One page per rule: docs/lint/rules/<plugin>/<rule>.mdx, 1,021 pages plus a generated index
• test/cli/lint/rule-docs.test.ts runs all 4,146 examples: what a page marks as reported has to be reported, what it marks as fine must not be. It also checks that every rule has a page and that the generated frontmatter is up to date.
• A generated ## Configure section on 984 pages: how to turn the rule on (or off, if it's on by default) in bunfig.toml. 407 of them also list every option, set to its default, one per line. The names, types and enum values come from the option schemas the linter validates against. bun lint --rules -f json has schema and default_options now. The test loads every snippet, and lints every example twice (rule only, and rule with the options snippet): the reports have to be identical, so a wrong default fails
• docs/runtime/lint.mdx rewritten: 214 lines, was 1,265
• src/lint/CLAUDE.md: how to write, register, document and test a rule
• docs/runtime/format.mdx rewritten: 295 lines, was 431
• Migration guides in docs/guides/lint and docs/guides/format

Writing the pages turned up about 300 notes about rules and pages that looked wrong. Each was checked against the original tool. The real bugs in rules that are on by default are fixed here, and the pages say what the rule does.

rule-docs.test.ts also runs all 1,512 toml snippets through bun fmt, so what the docs show is what the formatter prints.

docs/lint/rules is in .prettierignore: Prettier reformats the code in the examples, and many rules are about exactly that.

From review of #44805

• Tables of 256 bools are bit sets. ArrayBitSet::set and is_set are const fn, and bun_collections::ByteSet (32 bytes) can be a static. Scanning URL-like text: [bool; 256] 0.32 ns per byte, [u64; 4] 0.50, the match that was there before 0.79 (it compiles to a 376-byte jump table), u128 1.01. On a document that is 87% URLs, that is under 3% of Bun.markdown.html. Sets of one to three bytes use strings::contains_char / contains_any
• One glob matcher. src/glob (without the directory walker) goes from 9,235 lines to about 4,350. The ports of minimatch 10, minimatch 3, picomatch and brace-expansion are gone, along with their hard-coded limits. Lint and format convert other tools' patterns to Bun's syntax and use the same matcher as Bun.Glob. Why this is safe: an instrumented build asked Bun.Glob's matcher the same question at every real match call in 629 runs over 333 repos (1,870 patterns, 12.3 million calls). 90.1% of patterns already gave the same answer, 1.0% needed ?(..) / @(..), 8.8% differed only in what the caller passed in, and 2 patterns really differed. See "Bun.Glob" below for what changes there

Bun.Glob

The matcher rewrite also changes Bun.Glob:

• Extglob: ?(a|b), *(a|b), +(a|b), @(a|b), !(a|b). A ( without one of ?*+@! in front of it is still a plain character, so Next.js route groups like app/(marketing)/** match as before.
• Brace ranges: {1..3}, {01..10}, {a..e}, {1..9..2}. The number in the path is compared with the range. Nothing is expanded.
• No limits: braces used to stop working past 10 levels of nesting or 10,000 branches (the match returned false). Matching no longer recurses, so +(a|b) matches 100 KB of ab.
• Bug fixes: {a,b/**} matches b/x/y, {**,a}/b matches x/y/b, and an unclosed {a,b is treated as literal text (it used to match a but not b).

Patterns that change meaning. The new syntax takes some strings that used to be plain text, as in picomatch, minimatch and bash with extglob:

Pattern	Before	After
!(g)/a.ts	Everything but (g)/a.ts	a.ts in any folder but g
**/!(*.test).ts in scan()	Every file: a path component that starts with !( matched everything	.ts files that are not .test.ts
"workspaces": ["packages/!(b)"]	error: Workspace not found	Every package but b, as in npm, pnpm and yarn
*(1).txt, ?(1).js	copy(1).txt, i(1).js	Zero or more 1, then .txt. Write *[(]1).txt
A name with +(, @(, ?(, *( or !( in workspaces, sideEffects, files, --filter	That name	A group
{1..3}	The text 1..3	1, 2 or 3
An unclosed [, a trailing \	No match	Plain characters

Answers that were wrong in 1.4.3 and are right now. Each was run on the released binary.

pattern	path	1.4.3	now
{src/**,lib/**} (** inside braces was treated like *)	src/a/b.ts	false	true
{**,a}	x/y	false	true
{a,b} eleven times in a row (more than 10 brace groups)	b eleven times	false	true
braces nested 11 deep	the innermost alternative	false	true
a{ (an unclosed { is literal, as in bash and minimatch)	a{	false	true
{,	the empty string	true	false
*[!a]{,a}*	bc/	false	true

How often this matters. A search of public code (60 GitHub code-search requests) found 334 patterns with one of these sequences in a place Bun reads globs from: new Glob(...), workspaces, files, sideEffects, .npmignore, bunfig.toml, --filter. All of them use !(. 331 clearly mean extglob, 3 are unclear, and none relies on the old reading. About 13 are in repositories that use Bun. One test (in a repository with one star) pins "Bun.Glob has no extglob" and will fail. The search can't see patterns made at run time, private code, Bun Shell, or sideEffects in published packages.

File names. Only the pattern is parsed, never the path, so a file with such a name still matches **/*.ts. The one popular convention that contains a sequence is SvelteKit's layout reset, +page@(group).svelte: written out as a pattern, it no longer matches itself (**/+page*.svelte does). None of the 137 public lines that mention such a name is a glob. @scope, @modal, +page.svelte, (group) and (.)photo are unaffected. bun lint and bun fmt take the name of an existing file literally. On 12 patterns from that search, Bun.Glob agrees with minimatch 10 on all 12, and with picomatch 4 on 8: on the other 4 the two libraries disagree with each other.

A ( after anything else is still plain, so Program Files (x86), code (old), app/(group) and file(1).txt work as before: 34 commands (install, run, test, build, pack, lint, format, ...) in each of 23 oddly named project folders behave as in a plain folder.

Bun Shell is unaffected. Quoted text, ${} values and $VAR are still data: ${"@()!(zzz)"}/* matches nothing, and "c++(old)"/*.ts finds the folder. 391,551 fuzzed shell runs give the same result as before, except for symlinked folders whose name really contains +( or @(.

All 80,016 pattern and path pairs in test/js/bun/glob/match.test.ts give the same answer as before. Every pattern up to 6 characters long from the glob alphabet (113 million patterns, 26 paths, both platforms, every entry point, overflow checks on) runs without a panic.

How it works. A fast loop in front decides plain patterns and takes plain brace groups inline. Behind it is one automaton over the pattern's bytes: a single backward pass over the path with bit sets, where !(...) is the NOT of a bit that is already known. A pattern that is matched often (32 times, or once against a path of 512 bytes or more) switches to a cache of the automaton's states that is built as paths are matched. Matching does not recurse, and the time grows linearly with the length of the path.

Speed against Bun 1.4.3. CI's LTO build against the released binary, through new Bun.Glob(pattern).match(path), user instructions per call, 143 pairs of a pattern and a path. "Reused" is one Glob matched many times. "Fresh" is a new Glob for every match.

	faster	level (within 0.5%)	slower	all rows together
reused	142	0	1	2.7x faster
fresh	141	2	0	1.5x faster

pattern	path	1.4.3, reused	now	1.4.3, fresh	now
**/node_modules/**	a/node_modules/b/c.js	1,422	739	2,262	1,596
src/**/*.test.ts	lib/a/b/c.test.ts	400	349	1,230	1,107
{src/**,lib/**}	lib/a/b.ts	1,292	983	2,119	1,737
**/{src,lib}/**/{test,spec}/**/*.{ts,js}	packages/a/src/x/test/y/z.ts	3,136	866	3,914	2,889
!**/node_modules/**	src/a.ts	625	509	1,471	1,469
*.[jt]s	a.ts	602	433	1,390	1,327
a/**/b/**/c	a/x/b/y/c	983	550	1,791	1,414

The rows that are slower:

	pattern	path	1.4.3	now
reused	!!a	a	346	359

Every version of the matcher that landed was first compared with the previous one on 642 million pairs of a pattern and a path (107 jobs, debug assertions on: the same counts per job, no loop, no panic), and the last one on 1.1 billion more from tools aimed at its new fast paths. Those tools were themselves tested with deliberate one-line bugs. They found two wrong answers that three runs of the 642 million had missed (**/*[!a]*{a,b} on /abc/aa), both fixed, with tests.

scanSync() over 50,000 files, same files found:

Pattern	Before	After	Change
**/*.ts	157.1M	155.1M	-1.2%
**	423.9M	420.5M	-0.8%
p1*/src/**/*.js	95.7M	95.5M	-0.3%
**/*.{ts,tsx}	420.0M	351.6M	-16.3%

bun install in a 500-package monorepo with workspaces: ["packages/*", "apps/**"] is within noise (+0.3% to +0.8%, noise 0.5%). packages/!(internal), apps/@(web|api) and libs/lib{1..2} work as workspace entries. Every place that asks "is this string a glob?" (workspaces, sideEffects, bun pm diff, the walker's literal fast paths, the kernel filter on Windows) knows the new syntax.

The old src/glob still compiles in a test harness, so old and new were compared in one process: 10.2 million ignore lines for oxlint and oxfmt (1 differs, and there the new code matches real oxlint), 4.3 million override and .editorconfig patterns (0 differ). At the level of the product, 16,275 patterns went through each of 36 config options, one process each: 19 options are identical, and the rest differ on 1 to 104 broken patterns (*], (*), a bare |, unbalanced brackets) where the old code reproduced quirks of old minimatch versions.

JavaScript plugins

Third-party ESLint rules (plugins in an eslint.config.js, jsPlugins in an .oxlintrc.json) used to run in a 5,528-line JavaScript program embedded in the binary. It reimplemented ESLint's rule API on top of arrays of numbers that Rust serialized and copied over, on separate threads that the lint threads waited for.

• The rule API is native. TokenStore, SourceCode, context.report and the fixer, the scope manager's objects, code path analysis, selector matching and the order of listener calls are C++ and Rust. Objects are made from Structures that are built once and filled by offset. code_path.js, report.js, tokens.js and source_code.js are deleted, 1,976 lines of JavaScript are left, and about 500 of those only call other people's JavaScript (the project's own ESLint, Prettier and processors).
• JavaScript runs on the thread that lints the file. A thread that has a file with JavaScript rules owns a VM and does everything for that file: parse, built-in rules, plugin rules. How many threads get a VM still depends on memory and on how much work is left. The extra threads, the hand-off between them and the wake-up of every lint thread per file are gone.
• Nothing is copied. Native code reads Rust's tables for the file in place. The spans are cleared before Rust frees anything, and native methods only ever look at the current file's state, so an object that a plugin keeps from an earlier file can't reach freed memory.
• Only declared listeners are called, from a finished list. Rust works out which listeners get which node, in ESLint's order, with the code path events merged in. The JavaScript that's left is one loop over that list.

Instructions, release builds, lower is better. "Before" is #44805 as merged. Both builds were run alternately in one sitting, 4 threads, lowest of 3:

Run	Before	After	Change
199 ESLint core rules loaded as a plugin, 262 TypeScript files	51.16G	33.08G	-35%
A rule that listens for all seven code path events, 2,000 files	26.73G	9.99G	-63%
A rule that walks every scope, 2,000 files	17.34G	9.89G	-43%
getScope on a few nodes, 2,000 files	8.72G	9.08G	+4%
A rule that listens for *, 2,000 files	11.86G	6.32G	-47%
context.report on every identifier, 2,000 files	12.92G	8.87G	-31%
A report with merged fixes and a suggestion, 2,000 files	34.04G	21.49G	-37%
A rule that visits every Identifier, 200 small files	173.2M	100.3M	-42%
The same, plus getTokenBefore and getTokenAfter: cost of the two calls	38.4M	7.8M	-80%
12 token methods at every node, 200 small files	597.3M	192.1M	-68%
A plugin that does nothing, 200 small files, 1 thread	114.6M	63.1M	-45%
A plugin that does nothing, 1 file, 1 thread (start-up)	80.8M	33.5M	-59%

The first row is noisy: the old build against itself differs by 4% there, and its three runs of the second row by 6.5%. The three runs of every other row are within 0.9% of each other on the new build. The report of the first row is the same size to the byte on both builds. The row with a suggestion prints 8% more JSON on the new build, because a suggestion's data is passed through now.

1,200 files, one small plugin, 64 threads	Before	After	Change
Context switches	75,757	8,719	-88%
Peak memory	265 MB	151 MB	-43%

Slower:

• A rule that calls getScope on a few nodes: +4%.
• sourceCode.getText(node): +0.7% against the JavaScript it replaced (the JIT inlines text.slice, and a native call can't beat that).
• Nodes with the exact layout of espree and typescript-estree cost 1.2 to 1.4% more to build than the layout before, because loc is an own property now. Reading loc is 5% faster.
• Wall time for one small plugin at 4 threads with 3 VMs: 5 to 10% more, because no spare thread parses ahead any more.

Closer to ESLint. Everything was compared with real ESLint 10.12 (espree, and @typescript-eslint/parser 8.71.1) and real oxlint 1.87 over about 63,000 inputs. That turned up places where plugins could see a difference, now fixed:

• Nodes: own keys, their order, attributes, prototypes and loc now equal espree's and typescript-estree's. Whole trees are byte-identical in 63,185 of 63,195 files, and visitorKeys is byte-identical. Under an oxlint config, the layout of every node type equals oxlint 1.87's in all 25,658 TypeScript files that it parses.
• Scopes: own keys, their order, attributes and class names now equal eslint-scope and @typescript-eslint/scope-manager in all 25,765 and 37,428 files. In a first sample of 418 files, none matched. Values are identical in 25,763 and 37,415. thisFound, taints, the order of references, getDeclaredVariables and names from /* eslint-env */ comments were wrong. thisFound made unicorn/consistent-function-scoping report arrow functions that use this.
• Tokens and comments: the three layouts (espree, typescript-estree, oxlint), positions that aren't token boundaries, negative count and padding. Every method with every option form at every node, token, comment and text index: 63,184 of 63,193 files are identical.
• context.report: a report whose line or column isn't a number was dropped silently. ESLint's order of reads, RuleFixer as a class, a suggestion's data passed through.
• SourceCode: ESLint's ten own frozen properties in its order. loc of nodes in each parser's layout.
• Listeners get undefined as this, as in ESLint. They got an internal object.
• When a rule throws, the error of the first path is reported. Which one it was depended on timing.
• A plugin that puts an accessor with an index for a name on Array.prototype crashed the process (also in Add bun lint and bun format #44805).

The 9 files that still differ everywhere are Flow syntax in .tsx, where the syntax tree differs.

Visible outside bun lint and bun fmt

• Bun.Glob, and everything that uses it: see above.
• Bun.write(Bun.stdout, new Response(asyncIterable)) was a use-after-free when the reader of the pipe left while a write was parked (ASAN: heap-use-after-free in the pipe writer). The writer keeps its parent alive until close() returns. Same bug as io: POSIX pipe writers hold a ref on their parent from on_error until close() returns #34697
• Bun.spawn({ terminal }) could hang forever on macOS in a blocking wait4 on the JavaScript thread, when kqueue refused the exit watch. A port of spawn: reap a pty child on macOS when kqueue refuses the exit watch #41732. Fixes Bun.spawn({ terminal }): process hangs forever in __wait4_nocancel when a process-group signal races the child's own exit (macOS) #42171
• The TypeScript lexer behind bun check, bun lint and bun fmt used std::simd. It uses Highway like the rest of Bun, and std::simd, core::simd and feature(portable_simd) are banned by clippy and a source lint
• warn: is bold yellow in all of Bun's error output. It was dim.
• The ^ under an error is in the right column when the line has wide characters (CJK, emoji).
• Bun.markdown.ansi and bun file.md: a word that arrives in pieces, like `code` followed by . or ( followed by a link, is no longer split at the end of a line. The break goes to the last space.
• toHaveBeenCalledOnce() is in bun-types. The matcher already existed.
• A project's own lint, format or check script, file or binary still wins over the built-in command. --help, -h, --help-all and --doctor (and --explain for lint) now go to Bun, since no other tool has the last three and the migration guides send people there who still have "lint": "eslint .". Everything else, -v and --version included, reaches the script.
• bun init: the templates pass bun lint, bun lint --type-aware, bun check and bun fmt --check. The code that changed is formatting, types, async dropped from route handlers that don't await, and an unused req. frontend.tsx compiles to the same bytes as before in a plain transpile, an unminified build, with --react-fast-refresh and in the dev server's own transform. Every route answers with the same status, headers and body.
• Shell completions for lint and format.
• Start-up is unchanged: bun -e 1 +0.33% instructions, --version -0.22%, an empty file -0.12%, 20 Workers -0.11%, 1,000 ShadowRealms -0.14% (two runs of one build differ by 0.1 to 0.3%).

Binary size

Against main, in CI (the limit is 512 KB):

target
darwin-aarch64	+244.9 KB
darwin-x64	+238.4 KB
linux-aarch64	+320.0 KB
linux-x64	+260.0 KB
linux-aarch64-musl	+256.1 KB
linux-x64-musl	+256.1 KB
linux-aarch64-android	+384.1 KB
linux-x64-android	+292.1 KB
freebsd-x64	+240.1 KB
freebsd-aarch64	+248.1 KB
windows-x64	+349.0 KB
windows-aarch64	+356.5 KB

The rule pages for --explain are 304 KB of that, compressed. They're prose and examples: zstd at its highest level, xz and brotli all end within 3% of each other.

• Text that only bun lint, bun fmt and bun check read is zstd-compressed in the binary: the rule pages, option schemas, presets, bun check's 1,371 messages, oxlint's help and the JavaScript for plugins. That saves 432 KB. It's inflated on first use, which costs 146 to 202 µs for bun check's messages and 1.3M instructions when a plugin starts. Nothing the runtime loads is compressed. Text that an ordinary run would have to inflate (the names of globals, oxlint's category tables) is left as it is: 67 to 131 µs each.
• Report::fix, suggest_as, labels_with, help_with and hint_with were compiled once per closure: 832 copies, of which about 300 bytes each were the same code. That part is out of line now. 184 KB on a build without LTO, 241 to 276 KB per target in CI. A rule that reports nothing runs the same instructions as before, and a report with a fix costs 50 to 85 more.
• 12 sorts in cold rule code share one implementation: 84 KB. For each unstable one there's a reason why ties can't be seen. Two that turned out to run in every oxlint-config or typed run were put back.
• Standard-library sorts compiled once per closure and JSMap::set inlined five times in the plugin host: 62 KB.
• The three accessors for a file's scopes, variables and references are inlined in about 1,650 places, and each copy carried two cold blocks. They share one out-of-line exit now: 43 KB, and the common path is one instruction shorter.
• #[optimize(size)] on 258 functions that never run for a file or a config without errors: --doctor, --explain, --init, --print-config, --rules, --debug-check's comparison, and the functions that put a parser's error into oxlint's or ESLint's words. About 30% off each, 95 KB together. The rule is written next to each #![feature(optimize_attribute)]. Every function that got it had its callers read, and three that turned out to run on ordinary paths lost it again.
• The constructor for a syntax error was generic with about 140 call sites. It's a thin wrapper around one cold body.
• The shared sorts (src/collections/index_sort.rs) had 270 copies of 297 bytes, most of them on main too. 190 of those bytes build the list of indices, which doesn't depend on the element type, and every comparison closure was compiled twice, because the vtable of a &mut dyn FnMut also has a call_once slot that nothing calls (230 unused bodies). 64 KB. The algorithm, the indices and the comparisons are the same, so ties can't change. All seven entry points were compared with the standard sorts at lengths 0 to 5,000. The bundler, the installer and the runtime use these sorts too: a bundle of 3,000 modules costs the same (-0.1% to +0.04%).
• Why that last one was needed: the arm64 Linux files grow in steps of 64 KB, because a section is aligned to that. linux-aarch64-android read +448.1 KB and had 20,448 bytes left before a step to +512.1 KB, which fails the check by 72 bytes.

Removed

• Two source lints added by Add bun lint and bun format #44805: test/internal/source-lints/shared-helpers.test.ts and inner-allows.test.ts, with their inventories (about 1,640 lines). shared-helpers flags functions by name (trim, quoted, ...) anywhere in the repo, and inner-allows is a repo-wide policy on #![allow(..)] with an inventory of code this project doesn't own. They were useful while Add bun lint and bun format #44805 was being written, but as permanent CI they'd mostly get in other contributors' way. The other two lints from Add bun lint and bun format #44805 stay: sema-parser-recursion (guards against a real stack overflow) and shared-sorts (protects a 228 KB size saving, only looks at src/format).
• LICENSE.md: the rows from Add bun lint and bun format #44805 were audited against the tree. Rows for code that no longer exists are gone (the Svelte printer, the vue and jsdoc rules, minimatch, picomatch, brace-expansion), one wrong project was corrected, and about 30 missing credits were added. code_path.js, which is mostly ESLint's code, now carries ESLint's MIT notice.

How did you verify your code works?

• Every item ticked above was run on a release build of this branch, on made-up projects, the way a person would use it, including on a pseudo-terminal.

• New test files: defaults, hints, init, doctor, format-doctor, explain, help, output, native-rules, messages, rule-docs under test/cli/lint, and bunfig, words under test/cli/format.

• The upstream suites from Add bun lint and bun format #44805 are unchanged and pass.

• React defaults cost nothing measurable when they don't apply: 868 M instructions against 863 M on 3,000 .tsx files in 600 directories, and the same number of system calls.

• With an ESLint config (9 output formats) and an oxlint config (10), output before and after the hints is byte for byte the same.

• Real repositories. The merged build against this branch on 333 open-source repositories, each with its own config, arguments and installed node_modules, in a sandbox: 629 runs (204 oxlint, 108 ESLint, 243 oxfmt, 74 Prettier). 627 are identical in stdout and exit code. 1 is the thisFound fix above (discord.js: 4 false positives gone). 1 is a .toml file that's now formatted in a project with no Prettier config file. An earlier pass found a regression in 13 runs (an extra data key on react-hooks/exhaustive-deps suggestions in -f json), which is fixed. This pass ran after the native plugin host was complete.

• 199 ESLint core rules as a plugin on 262 TypeScript files: real ESLint and this branch agree on all 60,785 messages, in rule, position, text and fix.

• Each native piece went in behind a switch, was compared with the JavaScript it replaced and with the real tools, was made the default, and the JavaScript was deleted one green build later.

• Debug + ASAN with leak detection and BUN_JSC_validateExceptionChecks=1 before each deletion: the JavaScript plugin, parser, processor and Prettier plugin tests, plus an argument fuzzer for each native function (wrong types, Proxies, throwing getters, callbacks that call back in, objects kept from an earlier file, calls after the file has ended, forced GCs, low JIT thresholds).

• Config matching was reworked for speed, so it was compared before and after on 13,600 real files under five kinds of config, and on a made-up tree of 6,300 files (25 directories, 18 kinds of name, 14 extensions) under seven configs, with 1 and 8 threads: 22 runs, 150,000 lines of findings, all byte-identical. In debug builds every shortcut recomputes the full answer and compares.

• Every speed claim is user instructions on CI's LTO builds, main at the merge base against this branch, alternating, best of 3 or 4. Causes were found with exact counts (callgrind on both builds), not from samples: two sampled profiles pointed at the wrong functions.

• Three more reviews with the one aim of breaking the last day's work, on the built binary, reporting only what reproduces. CI was green and the review bot had found nothing.

  • Config matching: 2,170 before-and-after pairs (206 hand-picked patterns, 291 as overrides, 1,400 random configs from a grammar, either side of every limit, a React monorepo with packages nested both ways, files named .js, a..js, a{b,c}.js, a*.js and with invalid UTF-8) and 290 runs at 64 threads. Nothing.
  • The Prettier plugins, with real Prettier and the real plugins as the oracle: 20,000 classes in one attribute, 30 odd attribute shapes, 13 hostile Tailwind configs, monorepos, 11 odd folder names. No data loss, crash, silent unsorted output or nondeterminism. Found seven bugs at the edges, all fixed: --allow-unsupported turned off the package.json hand-off, so it wrote other bytes than bun fmt; "" in a path option was read as a path; null was accepted; a refusal blamed JSON and not the plugin; one run said a plugin has no effect and refused files because of it.
  • Positions and output: 772,330 messages equal to real ESLint's in line, column, end line and end column, 983,030 findings under an oxlint config equal in 14 formats, files of 63 to 4,097 lines with the only non-ASCII line at every edge, 60 open-source projects. Found that the faster -f unix printed 2:7 for a plugin's loc past the end of a line, where oxlint and every other format say 3:3. Fixed. Found the order under overrides above.

• Threads: 8 configs at 1, 4, 16 and 64 threads give one report hash per config. 600 stress runs with a timeout had no hang.

• A final review in five passes, with CI green and the 333 repositories identical, each looking for what all of that had missed:

  • As a first-time user, on seven made-up projects and the four templates. Found the false errors in "Default rules". Second round: every error left in the code projects is a planted bug, and none of the fixes cost a real catch (16 hook misuses, 7 of 7 stray characters in code, 7 kinds of real fallthrough are still reported).
  • As someone migrating, about 980 commands with real plugins, most of them three ways (real tool, main, this branch), comparing stdout, exit code, and the hash, mode and inode of every file. No regression under any ESLint, oxlint, Prettier or oxfmt config. Found the --parser data loss and the oxlint gaps above. 63 path idioms with 4 tools, 30 stdin shapes, 26 --fix flag combinations: Bun never writes a file the real tool wouldn't, apart from "no arguments means the current directory".
  • The plugin host's memory safety. Found two segfaults, the abort, and two ways for a plugin to reach the host's internals, all fixed. Then: 2,250 fuzz seeds (hostile arguments, Proxies, re-entrant callbacks, 21 kinds of prototype pollution), 3,600 runs at 2 to 64 threads, VMs freed mid-run, objects kept from earlier files under ASAN with forced GCs, 22 odd encodings, 144 very deep files: no crash, no deadlock.
  • Bun.Glob and everything that uses it. Found that quoted text in Bun Shell had become glob syntax, and two .prettierignore lines that differed from Prettier, both fixed. Found that match() had become quadratic in the length of the path, and then an endless loop and wrong answers in the first fix for that. All fixed: matching is linear, and see "Speed against Bun 1.4.3". Then: every pattern of up to 5 tokens (6.7M patterns, 64 paths), 111M fuzzed pairs of well-formed old syntax (22 patterns differ, and there the old answer was the bug), 151M crash-fuzz pairs, 623,616 scanSync calls over all 32 option combinations, 54,240 ignore lines against the npm package (0 differ).
  • Everything outside lint and format. Found that flags skipped a project's own lint script, and the two commands that wrote files. Then: 11 project shapes, 3 commands and 65 command lines against main and 1.4.3, a 253-command smoke comparison, 16 bunfig files with 10 commands: only the differences listed above.

[robobun]

^{Updated 10:52 PM PT - Oct 12th, 2026}

@Jarred-Sumner, your commit dcbdac3 is building: #125010

[claude]

Findings marked 🟡 are optional suggestions and need no follow-up push.

[claude]

Findings marked 🟡 are optional suggestions and need no follow-up push.

Still open from earlier reviews (7):

• 🔴 src/glob/matcher.rs:721 — A glob that ends with a backslash inside an unclosed [ now crashes bun lint and bun format with a Rust panic, where the…
• 🔴 src/lint/driver/doctor.rs:542 — Users of bun lint --doctor are told they can remove build packages that merely contain "eslint" in their name, such as…
• 🔴 src/lint/driver/fmt/editorconfig.rs:128 — Projects whose glob patterns use a brace sequence such as {1..3} or {a..c} silently stop matching those files after mer…
• 🔴 src/lint/plugins/import_minimatch.rs:49 — ESLint users with eslint-plugin-import rules get different reports after merging: patterns now match names that start w…
• 🔴 src/md/ansi_renderer.rs:1057 — CI's source lint fails on this line, so the PR cannot merge green: since.contains(&b'\n') is the byte-literal <[u8]>::c…
• Also unresolved: 2 minor or pre-existing.

If you have decided not to act on one of these findings, resolve its thread (a reply alone leaves it open) and the next review stops counting it. To review this commit again now, use Re-run on its "Claude Code Review" check.

[claude]

Findings marked 🟡 are optional suggestions and need no follow-up push.

Still open from earlier reviews (1):

• Unresolved: 1 minor or pre-existing.

Additional findings (outside the current diff — GitHub can't attach inline comments there):

• 🔴 test/internal/source-lints/inner-allows.test.ts:1 — Maintainers lose two ratcheted source-lint safety nets after merging: the latest commit deletes test/internal/source-lints/inner-allows.test.ts and shared-helpers.test.ts with their inventory files, so a new crate-wide #![allow(..)] or a re-implemented text/path helper in a non-shared crate no longer fails CI. Neither the PR description nor the commit message states a reason or a replacement, and the diff adds no #![allow( that would have needed one. Fix: restore the two tests and their inventories (updating the inventories with --update if the PR moved or removed entries), or state in the PR why they go and what now enforces the same invariants. [also at: test/internal/source-lints/shared-helpers.test.ts:1 - Maintainers lose two CI safety nets with no stated reason: the latest push deletes test/internal/source-lints/shared-helpers.test.ts and test/internal/source-lints/inner-allows.test.ts with their inventory JSON files.; src/lint/CLAUDE.md:172 - Maintainers lose two CI safety nets with no stated reason: the latest push deletes test/internal/source-lints/shared-helpers.test.ts and inner-allows.test.ts together with their inventory files, so a new #![allow(..)] in a crate or a private copy of a text/path helper no longer fails CI as it did on the base branch.]

  Why this was flagged

  Commit eafd737 ("lint, format: 153 files") deletes test/internal/source-lints/inner-allows.test.ts, inner-allows.inventory.json, shared-helpers.test.ts and shared-helpers.inventory.json. On the base branch inner-allows.test.ts asserts that no new #![allow(..)]/#![expect(..)] appears in any tracked .rs file beyond the ratcheted inventory, and shared-helpers.test.ts asserts that no free function with a shared-helper name is re-implemented outside src/bun_core, src/paths, src/collections etc. A repo-wide grep for inner-allows and shared-helpers at HEAD finds nothing, so nothing references or replaces them. A grep of the diff for added #![allow( or #![expect( finds no hits, so the deletion is not needed to make this PR pass. After merging, CI no longer catches either regression class; the PR description lists no such removal and the review instructions require a stated reason or replacement for every deleted safety net.

  Verification: normal — triggered the first time a future PR adds a crate-/module-wide #![allow(..)] or a re-implemented text/path helper in a non-shared crate: CI no longer catches it. git diff c39c718b..HEAD --stat -- test/internal/source-lints/ shows four pure deletions, attributed solely to eafd737, whose commit body is empty. A repo-wide grep for inner-allows|shared-helpers returns nothing in HEAD.

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

[claude]

Findings marked 🟡 are optional suggestions and need no follow-up push.

Still open from earlier reviews (1):

• Unresolved: 1 minor or pre-existing.

[claude]

Findings marked 🟡 are optional suggestions and need no follow-up push.

Still open from earlier reviews (2):

• 🔴 src/lint/driver/native.rs:237 — Users without a config who turn on a typed pair rule by its typescript-eslint name, such as @ typescript-eslint/require…
• Also unresolved: 1 minor or pre-existing.

If you have decided not to act on one of these findings, resolve its thread (a reply alone leaves it open) and the next review stops counting it. To review this commit again now, use Re-run on its "Claude Code Review" check.

[claude]

The last 3 reviews of this pull request each found new blocking issues. Where they share a root cause, one fix may close them together.

[claude]

Findings marked 🟡 are optional suggestions and need no follow-up push.

The last 4 reviews of this pull request each found new blocking issues. Where they share a root cause, one fix may close them together.

Still open from earlier reviews (1):

• 🔴 src/lint/driver/configs.rs:755 — Users who add [[lint.overrides]] to bunfig.toml and run bun lint from a subdirectory of an ESLint flat-config project l…

If you have decided not to act on one of these findings, resolve its thread (a reply alone leaves it open) and the next review stops counting it. To review this commit again now, use Re-run on its "Claude Code Review" check.