Connor Shea

Good. Don't stand down, Anthropic. www.anthropic.com/news/stateme...

Review it like you would a PR from Linus Torvalds

Please report any bugs you've found so that we can fix them 🙏 github.com/oxc-project/...

@ericmbudd.com undefined

"if you accept arbitrary regexes you can make the system slow" is such a funny class of "vulnerability", like... yeah, no shit.

JS Plugins A collection of high-performance JavaScript tools written in Rust

Depending on the specific custom rules you've got, JS Plugins in Oxlint may be usable without much trouble :) oxc.rs/docs/guide/u...

Also see oxc.rs/docs/guide/u...

Proof of Concept: Script for comparing JS-generated upstream test cases by connorshea · Pull Request #19394 · oxc-project/oxc DISCLAIMER: Fully written by Claude Code / Opus 4.6. I'm opening this now because I think it's really useful and wanted to share it before I had to hop off for the day. I have not reviewed ...

I have forced Claude to build a proof of concept for this that should make it a lot easier to find dynamically-generated tests from the original rules :) github.com/oxc-project/...

test(linter): Add more tests for the `eslint/no-empty-function` rule. by connorshea · Pull Request #19392 · oxc-project/oxc This ports various tests from the original rule, all were added upstream in eslint/eslint@dcd95aa Most of them pass, but a few needed to be commented out. All of this work was done manually, no Cla...

I already went through and did this work via automation for a lot of rules, but our rulegen tooling doesn't support retrieving tests that are generated dynamically, so I know for certain that some are missing cases still.

For example: github.com/oxc-project/...

If anyone wants to give me tons of credits to use for LLM nonsense, I think running one in a loop to find Oxlint rules that are missing test cases from the original plugins would be neat.

LLMs seem to absolutely love generating GitHub Actions configs that use versions that are multiple major releases behind, like @actions/checkout v4 instead of v6. The GitHub team should probably be proactive about mitigating this somehow...

Sometimes I think semantic versioning is worse for software than not using it. Like, it'd sometimes be better to have smaller, incremental jumps that break things rather than major version bumps that have 20 breaking changes all at once. You *can* do this with semantic versioning, but no one does.

Building a C compiler with a team of parallel Claudes Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.

Prediction for this year: AWS earns $10 trillion in 2026 as Claude rewrites everything in Rust. In January 2027, we run out of things to rewrite and the economy collapses entirely. www.anthropic.com/engineering/...

I dunno about underhyped, but a lot of things are definitely about to change.

The software you can create with these models has beaten by expectations repeatedly, as has unfortunately the image generation.

A dropdown that says "Rules" with a search box where "arrow" has been input. The dropdown has two results: "eslint/arrow-body-style" and "vue/no-arrow-functions-in-watch".

The oxc playground UI with a sidebar that has the "eslint/no-console" rule selected. In the main view there is a code editor with the following example code: ``` console.log("foo"); // error because we set the no-console linter rule. debugger; // allowed because no other rules are enabled. ```

I have updated the oxlint playground with a linter rule picker, so now you can easily use the playground for reproduction/issue reporting when there are bugs :) Or just play around with oxlint a bit more easily!

playground.oxc.rs

As of a few days ago the JS Plugins system passes the full ESLint core test suite (excluding some edge cases like tests using "globals" comments which we don't support) and also the test suite for the react-hooks plugin, if that's any comfort :) github.com/oxc-project/...

The linting situation for React codebases feels a bit dire...

eslint-plugin-react is extremely outdated, and its docs don't communicate that a lot of its rules are no longer relevant for modern React code (many are only applicable for class-based components).

Support ESLint-style bulk suppression via suppressions file · Issue #10549 · oxc-project/oxc Our team is evaluating Oxlint for our projects and are impressed by its performance. However, we've been anticipating ESLint's bulk suppression feature, which aligns well with our workflow. We have...

I think a bulk suppression system like Rubocop (called "rubocop-todo") and ESLint support is also a good way to do this. And Oxlint will add it sometime in the near-ish future. github.com/oxc-project/...

Our relationship with the dark lord has been long and fruitful

Alex Pretti was murdered for no reason, despicable and pure fucking evil. Executing citizens who have done nothing wrong.

The video makes me completely sick to my stomach. This secret police charade needs to be removed from Minnesota and dismantled entirely, before this can spiral any further.

It has been populated with info about which rules are recommended in the original ESLint plugins that Oxlint's rules come from, and also allows you to pick from a few JS Plugins that are supported via the ESLint plugin compatibility work the oxc team has done :)

Screenshot from the website, which features a basic UI for selecting linter plugins, filtering and selecting linter rules, and viewing and copying the generated JSON config file.

I created a quick proof-of-concept for an Oxlint config generator website.

If you start a new project or have an existing project, and want to set up an Oxlint config from scratch, hopefully it's useful!
connorshea.github.io/oxlint-confi...

no and no

YouTube video by Tom Scott I tried using AI. It scared me.

I can't believe this video is almost 3 years old now. I think about it a lot. Nowadays I use LLMs a lot for basic/tedious code.

I'm still not totally sure where we're at on the S-curve, but - at least in software engineering - it's getting really wild out there. www.youtube.com/watch?v=jPhJ...

A screenshot of a terminal window with an error message from Oxlint. The error message says: Failed to parse oxlint configuration file. × Invalid configuration for rule `import/no-absolute-path`: unknown field `foobar`, expected one of `esmodule`, `commonjs`, `amd`, received `{ "foobar": true }` │ Invalid configuration for rule `import/no-duplicates`: invalid type: string "maybe", expected a boolean, received `{ "preferInline": "maybe" }` │ Invalid configuration for rule `no-cond-assign`: invalid type: integer `123`, expected string or map, received `123` │ Invalid configuration for rule `vue/define-emits-declaration`: unknown variant `declaration`, expected one of `type-based`, `type-literal`, `runtime`, received `{ "declaration": 0 }`

For example :)

feat(linter): Update 125 rules to raise errors when provided with invalid config options. by connorshea · Pull Request #18104 · oxc-project/oxc Ran oxc-ecosystem-ci and it passed fine, no diff vs. main: https://github.com/oxc-project/oxc-ecosystem-ci/actions/runs/21199291772 Trial by fire, I guess. If this is too big of a change, we can sp...

Merged a change for Oxlint that is the culmination of a *lot* of work by many people over the last year+. Took a lot of work to define the options schemas, standardize most of the rules, and update linter rule logic to enable options validation like this :)
github.com/oxc-project/...

GitHub - oasis-tcs/sarif-spec: OASIS SARIF TC: Repository for development of the draft standard, where requests for modification should be made via Github Issues OASIS SARIF TC: Repository for development of the draft standard, where requests for modification should be made via Github Issues - oasis-tcs/sarif-spec

Ooh this exists and seems promising 👀 github.com/oasis-tcs/sa...

Some tools use JUnit test reports as a hack for this, but it's not really very good for that. GitLab Code Quality is _okay_ for this, but not really that good versus what I'd ideally like to see for something like this. It'd be great to have autofix integration in a CI pipeline as well.

My conclusion after trying to find any good, standard integration format for Linters/Formatters in a CI tool is: there are none. GitLab CI has Code Quality, GitHub Actions has annotations, but nobody else has anything specific really, and none are standardized.

I like this concept, what do you think @boshen.github.io?

A prompt in the Graphite code review tool that says "Translate your existing git workflow to the equivalent Graphite commands."

Why use other workflow when my workflow do trick? (but seriously why would I want to use not-git when I have 10 years of experience with git)