I work on a project where we recently heavily pivoted into AI assisted feature development and without a extremely defensive/aggressive lint config and test coverage near ~80% most of these developments would be quiet impossible.
`no-reflect-get` is definitely one I'd adopt, claude LOVES `Reflect.get` for some reason
Can't yet- at least not fully without the custom rule API, we have ~10+ lint rules across various repos and I don't want to run a hybrid eslint+oxlint thing.
oxlint and some general ast-grep rules have pretty much been an absolute necessity for any of my LLM based code generation. I started down this path after looking at what coderabbit suggested in https://github.com/coderabbitai/ast-grep-essentials
A few more rules that I added personally, and a few standard rules. Its more of a centralization of cool rules that are more llm friendly.
- tailwind cannonical class rule
- duplicate types and consts (take zod/drizzle schema inference into account)
Also not a fan of installing skills for something that should be a package. Didn't like how dmmulroy had that as the install method. This just makes it super convenient.
I occasionally add more rules as I see more common ai slop
10 comments
[ 0.50 ms ] story [ 21.7 ms ] threadI’m personally using both oxlint for typescript and my own vibe coded tool for doing cross language rules ast rules and llm hook outputs.
And recently added vale as well.
`no-reflect-get` is definitely one I'd adopt, claude LOVES `Reflect.get` for some reason
A lot of the lint rules in this repo remind me of https://github.com/sindresorhus/eslint-plugin-unicorn, I can't wait until oxlint has plugin support so I can move over to it.
But if any others, let me know, and feel free to make a pr!
But what does this add beyond that?
Also not a fan of installing skills for something that should be a package. Didn't like how dmmulroy had that as the install method. This just makes it super convenient.
I occasionally add more rules as I see more common ai slop