Brad Zacher
@brad.zacher.com.au
Computer scientist. Cider drinker. Dungeon Master.
Maintainer of @typescript-eslint.io
Software Engineer @ Canva.
https://zacher.com.au
Maintainer of @typescript-eslint.io
Software Engineer @ Canva.
https://zacher.com.au
I am violating semver. Pray I don't violate it any further.
November 11, 2025 at 1:52 PM
I am violating semver. Pray I don't violate it any further.
I did some research and I remember seeing a few issues showing the react team wasn't really interested in rewriting it in rust themselves, but they would support the OXC and SWC folks to write their own implementations.
(don't have links handy right now sorry)
(don't have links handy right now sorry)
November 2, 2025 at 8:00 AM
I did some research and I remember seeing a few issues showing the react team wasn't really interested in rewriting it in rust themselves, but they would support the OXC and SWC folks to write their own implementations.
(don't have links handy right now sorry)
(don't have links handy right now sorry)
It's not just the parsing that's the issue - the lint rules work by running the compiler. Which means a babel parse AND a babel traverse and babel transform pass on each file as part of the lint run.
The extra parse is just a small piece of the slowness.
The extra parse is just a small piece of the slowness.
November 2, 2025 at 8:00 AM
It's not just the parsing that's the issue - the lint rules work by running the compiler. Which means a babel parse AND a babel traverse and babel transform pass on each file as part of the lint run.
The extra parse is just a small piece of the slowness.
The extra parse is just a small piece of the slowness.
I don't think we did try the compiler for bundles because our codebase is quite the mess. Also we use mobx so we wouldn't get massive wins from using the compiler.
But we tried the lint rules because it would help us plan migrations and future work in this direction.
But we tried the lint rules because it would help us plan migrations and future work in this direction.
November 2, 2025 at 8:00 AM
I don't think we did try the compiler for bundles because our codebase is quite the mess. Also we use mobx so we wouldn't get massive wins from using the compiler.
But we tried the lint rules because it would help us plan migrations and future work in this direction.
But we tried the lint rules because it would help us plan migrations and future work in this direction.
We tried turning the lint rules on and it over doubled our already considerable eslint times. The compiler lint rules do their own babel parse during the lint run (I.e doubling the number of parses per file).
November 2, 2025 at 1:00 AM
We tried turning the lint rules on and it over doubled our already considerable eslint times. The compiler lint rules do their own babel parse during the lint run (I.e doubling the number of parses per file).
We found the same perf problems at Canva.
The problem with building on top of babel in JS is perf sucks at scale compared to rust toolchains.
The problem with building on top of babel in JS is perf sucks at scale compared to rust toolchains.
November 2, 2025 at 1:00 AM
We found the same perf problems at Canva.
The problem with building on top of babel in JS is perf sucks at scale compared to rust toolchains.
The problem with building on top of babel in JS is perf sucks at scale compared to rust toolchains.
Honestly TLA should be disallowed in imported modules. It is a great feature for entrypoint files at the root, but not for imported files. I think that was the great failing of the spec, personally.
October 30, 2025 at 7:06 AM
Honestly TLA should be disallowed in imported modules. It is a great feature for entrypoint files at the root, but not for imported files. I think that was the great failing of the spec, personally.
@jameshenry.bsky.social set it up after the NX breach and its a great system that also means there are the provenance attestations visible on the NPM packages - helping users to the security that exists.
September 9, 2025 at 10:31 PM
@jameshenry.bsky.social set it up after the NX breach and its a great system that also means there are the provenance attestations visible on the NPM packages - helping users to the security that exists.
docs.npmjs.com/trusted-publ...
docs.github.com/en/actions/h...
If you're using github actions it's a bit of work but easy enough to truly lock down the publishing so it can only be done via a GH action workflow from specific branches by combining trusted publishers with GH environments.
docs.github.com/en/actions/h...
If you're using github actions it's a bit of work but easy enough to truly lock down the publishing so it can only be done via a GH action workflow from specific branches by combining trusted publishers with GH environments.
Trusted publishing for npm packages | npm Docs
Documentation for the npm registry, website, and command-line interface
docs.npmjs.com
September 9, 2025 at 10:31 PM
docs.npmjs.com/trusted-publ...
docs.github.com/en/actions/h...
If you're using github actions it's a bit of work but easy enough to truly lock down the publishing so it can only be done via a GH action workflow from specific branches by combining trusted publishers with GH environments.
docs.github.com/en/actions/h...
If you're using github actions it's a bit of work but easy enough to truly lock down the publishing so it can only be done via a GH action workflow from specific branches by combining trusted publishers with GH environments.
Both tools are written in rust which (unlike JS...) makes adding concurrency a breeze. Which is why they both already have it as a first-class feature.
It's so easy to do concurrency when you can share memory freely between threads.
It's so easy to do concurrency when you can share memory freely between threads.
September 6, 2025 at 10:01 PM
Both tools are written in rust which (unlike JS...) makes adding concurrency a breeze. Which is why they both already have it as a first-class feature.
It's so easy to do concurrency when you can share memory freely between threads.
It's so easy to do concurrency when you can share memory freely between threads.
Oxlint has cross-file linting (their no-cycles rule) and they are a highly parallelised tool.
They're also working on type-aware linting via tsgolint. So they'll surely have a plan to ensure it is as highly parallelised as possible.
They're also working on type-aware linting via tsgolint. So they'll surely have a plan to ensure it is as highly parallelised as possible.
September 6, 2025 at 10:01 PM
Oxlint has cross-file linting (their no-cycles rule) and they are a highly parallelised tool.
They're also working on type-aware linting via tsgolint. So they'll surely have a plan to ensure it is as highly parallelised as possible.
They're also working on type-aware linting via tsgolint. So they'll surely have a plan to ensure it is as highly parallelised as possible.
I know biome now has their psuedo-type-aware linting which is cross-file. So they would surely have affordances for concurrent cross-file linting.
September 6, 2025 at 10:01 PM
I know biome now has their psuedo-type-aware linting which is cross-file. So they would surely have affordances for concurrent cross-file linting.
So it should be faster than a non-parallel run as the rules all parallelise, but it will have a hard floor in the form of computing the type info.
August 14, 2025 at 10:34 PM
So it should be faster than a non-parallel run as the rules all parallelise, but it will have a hard floor in the form of computing the type info.
It will work, in a manner of speaking - there will just be a bit of duplicated effort.
In a nutshell because we cannot influence the chunking of files one tsconfig's files may get split across two threads - which will cause the type info to be computed twice.
In a nutshell because we cannot influence the chunking of files one tsconfig's files may get split across two threads - which will cause the type info to be computed twice.
August 14, 2025 at 10:34 PM
It will work, in a manner of speaking - there will just be a bit of duplicated effort.
In a nutshell because we cannot influence the chunking of files one tsconfig's files may get split across two threads - which will cause the type info to be computed twice.
In a nutshell because we cannot influence the chunking of files one tsconfig's files may get split across two threads - which will cause the type info to be computed twice.
There's also been some mild concern because some of these PRs has come from brand new GH accounts with few or no other contributions.
Kind of makes me think unscrupulous individuals are using AI to make fake accounts look more legitimate with very little effort.
Kind of makes me think unscrupulous individuals are using AI to make fake accounts look more legitimate with very little effort.
July 23, 2025 at 11:29 PM
There's also been some mild concern because some of these PRs has come from brand new GH accounts with few or no other contributions.
Kind of makes me think unscrupulous individuals are using AI to make fake accounts look more legitimate with very little effort.
Kind of makes me think unscrupulous individuals are using AI to make fake accounts look more legitimate with very little effort.
Someone emailed our security email last week asking us to upgrade a dependency from 0.5.2 to 0.5.3 because it resolved a CVE.
The CVE was ReDoS - so not an issue.
And our declared dependency semver is ^0.5.2 - so they'd get the new version if they fixed their lock file.
🤡🤡🤡🤡
The CVE was ReDoS - so not an issue.
And our declared dependency semver is ^0.5.2 - so they'd get the new version if they fixed their lock file.
🤡🤡🤡🤡
April 10, 2025 at 10:23 AM
Someone emailed our security email last week asking us to upgrade a dependency from 0.5.2 to 0.5.3 because it resolved a CVE.
The CVE was ReDoS - so not an issue.
And our declared dependency semver is ^0.5.2 - so they'd get the new version if they fixed their lock file.
🤡🤡🤡🤡
The CVE was ReDoS - so not an issue.
And our declared dependency semver is ^0.5.2 - so they'd get the new version if they fixed their lock file.
🤡🤡🤡🤡
> I see we have an issue - we accidentally removed the actual implementation of the TUI when trying to fix the imports.
Yes, that's right -- the AI wrote a bunch of code AND THEN DELETED ALL OF ITS CODE *ACCIDENTALLY*.
Don't worry folks -- our jobs are safe.
Yes, that's right -- the AI wrote a bunch of code AND THEN DELETED ALL OF ITS CODE *ACCIDENTALLY*.
Don't worry folks -- our jobs are safe.
February 12, 2025 at 8:44 PM
> I see we have an issue - we accidentally removed the actual implementation of the TUI when trying to fix the imports.
Yes, that's right -- the AI wrote a bunch of code AND THEN DELETED ALL OF ITS CODE *ACCIDENTALLY*.
Don't worry folks -- our jobs are safe.
Yes, that's right -- the AI wrote a bunch of code AND THEN DELETED ALL OF ITS CODE *ACCIDENTALLY*.
Don't worry folks -- our jobs are safe.
Miette is so sexy and it does also support syntax highlighting too.
I use it on an internal tool at Canva (a meta linter like arc lint) and it looks so good. Very flexible too!
Many of your favourite rust tools use it! (I think swc and oxc both use it)
I use it on an internal tool at Canva (a meta linter like arc lint) and it looks so good. Very flexible too!
Many of your favourite rust tools use it! (I think swc and oxc both use it)
January 4, 2025 at 1:52 PM
Miette is so sexy and it does also support syntax highlighting too.
I use it on an internal tool at Canva (a meta linter like arc lint) and it looks so good. Very flexible too!
Many of your favourite rust tools use it! (I think swc and oxc both use it)
I use it on an internal tool at Canva (a meta linter like arc lint) and it looks so good. Very flexible too!
Many of your favourite rust tools use it! (I think swc and oxc both use it)