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
Even at Canva with "just" 1500 engs - I'd doubt that most of the (about 700) FEs could pass this test.
Heck my job at Canva is building and maintaining FE dev infra (including maintaining a complex webpack setup) and I would completely and utterly fail this test.
Heck my job at Canva is building and maintaining FE dev infra (including maintaining a complex webpack setup) and I would completely and utterly fail this test.
November 16, 2025 at 11:06 AM
Even at Canva with "just" 1500 engs - I'd doubt that most of the (about 700) FEs could pass this test.
Heck my job at Canva is building and maintaining FE dev infra (including maintaining a complex webpack setup) and I would completely and utterly fail this test.
Heck my job at Canva is building and maintaining FE dev infra (including maintaining a complex webpack setup) and I would completely and utterly fail this test.
That's not to say they couldn't learn it quickly on-the-job given the need...
But putting someone on the spot to do something they mightn't have done for years would ofc be a fast path to failure.
You'd probably find the same of most big tech engs TBH. It's just how big companies work.
But putting someone on the spot to do something they mightn't have done for years would ofc be a fast path to failure.
You'd probably find the same of most big tech engs TBH. It's just how big companies work.
November 16, 2025 at 11:06 AM
That's not to say they couldn't learn it quickly on-the-job given the need...
But putting someone on the spot to do something they mightn't have done for years would ofc be a fast path to failure.
You'd probably find the same of most big tech engs TBH. It's just how big companies work.
But putting someone on the spot to do something they mightn't have done for years would ofc be a fast path to failure.
You'd probably find the same of most big tech engs TBH. It's just how big companies work.
As an ex-Meta - not surprising at all.
At FB as a FE all you do is write your product code - NOTHING else.
The infra - build, deployment, linter, formatter, CI, devbox, EVERYTHING - is done by other teams.
Unless they kept up with OSS in their free time - the knowledge wouldn't be there at all.
At FB as a FE all you do is write your product code - NOTHING else.
The infra - build, deployment, linter, formatter, CI, devbox, EVERYTHING - is done by other teams.
Unless they kept up with OSS in their free time - the knowledge wouldn't be there at all.
November 16, 2025 at 11:06 AM
As an ex-Meta - not surprising at all.
At FB as a FE all you do is write your product code - NOTHING else.
The infra - build, deployment, linter, formatter, CI, devbox, EVERYTHING - is done by other teams.
Unless they kept up with OSS in their free time - the knowledge wouldn't be there at all.
At FB as a FE all you do is write your product code - NOTHING else.
The infra - build, deployment, linter, formatter, CI, devbox, EVERYTHING - is done by other teams.
Unless they kept up with OSS in their free time - the knowledge wouldn't be there at all.
We've also got a plan to eliminate all globals by patching any dts files that declare modules and wrapping them with importable modules - cos implicit globals are ultimately such a horrible thing.
November 16, 2025 at 7:02 AM
We've also got a plan to eliminate all globals by patching any dts files that declare modules and wrapping them with importable modules - cos implicit globals are ultimately such a horrible thing.
The globals we include by manually adding to the tsconfig which our build file generator automatically picks up and lists as a bazel dep.
You're right that it's mostly a rare case so no need to do anything too fancy.
We have exceptions for common cases like jest or node which we add automatically.
You're right that it's mostly a rare case so no need to do anything too fancy.
We have exceptions for common cases like jest or node which we add automatically.
November 16, 2025 at 6:46 AM
The globals we include by manually adding to the tsconfig which our build file generator automatically picks up and lists as a bazel dep.
You're right that it's mostly a rare case so no need to do anything too fancy.
We have exceptions for common cases like jest or node which we add automatically.
You're right that it's mostly a rare case so no need to do anything too fancy.
We have exceptions for common cases like jest or node which we add automatically.
The fact that I have to manually grab the URL when reporting...
November 14, 2025 at 7:08 PM
The fact that I have to manually grab the URL when reporting...
The number of times people suggest this for lint rules...
> Add a feature that does something
< We don't think this is a good idea
> Just add a default off option and people that want it can turn it on
> Add a feature that does something
< We don't think this is a good idea
> Just add a default off option and people that want it can turn it on
November 14, 2025 at 7:08 PM
The number of times people suggest this for lint rules...
> Add a feature that does something
< We don't think this is a good idea
> Just add a default off option and people that want it can turn it on
> Add a feature that does something
< We don't think this is a good idea
> Just add a default off option and people that want it can turn it on
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.