Hacker News new | past | comments | ask | show | jobs | submit login

It will be awesome when this gains support for custom rules as I have a bunch of custom ESLint rules. The thing that annoys me the most about ESLint is that it has too many NPM dependencies.



This feels like the most important thing about new linters (including the one Bun has and others).

If you just use linting for checking a bit of stylistic policy, any replacement might be fine. However, linting is much more than that and if you are depending on third party rules or writing your own ([link redacted]), there is no way around ESLint.


Not sure if I’d be comfortable taking as far as your example.

Adding logic into linters blurs separation of concerns, adding unnecessary complexity akin to an extra programming language.

Linting in essence should be orthogonal to development — a layer that enhances code quality without being fundamental to the code’s functionality. By overextending linting, we risk creating a maintenance burden and an additional learning curve for developers.

Linting is a great tool and but as with any great hammer it’s easy for lots of things to start to look like nails.


eslint and typescript are the de-facto static analysis tools for JavaScript. TypeScript isn't extensible. So if you want to do any custom static analysis, you're doing it as a custom eslint plugin.

It might be better to have some other tool to do pluggable static analysis, but the fact is that there isn't one. And eschewing project-specific static analysis entirely would be giving up far too much.


I use custom linters as a “continuous codemod” that transform old code and engineer habit in form X to new form Y. Combined with a way to “ratchet” the number of rule violations towards zero, we can gradually and relatively painlessly roll out any number of whole codebase migrations in parallel over weeks or months.

Two examples:

- we have an API like dbModel.getValue() that subscribes the current view to any change in an entire database row. We noticed this lead to UI performance issues from components over-rendering. To deprecate, I wrote a rule to transform dbModel.getValue().specificProp to dbModel.getSpecificProp(). We can’t remove the getValue method since there’s times you really do need it, but we can automatically switch new code written to a more performant specific call for many cases.

- We use a lint rule to enforce that API endpoints and queue worker jobs have ownership and monitoring rules specified. We could use the type system to strictly enforce this, but we want to support gradual migration as well as suggest some inferred values based on the identity of the author. Using a lint with ratcheting means newly added cases are enforced but easy to add, and old cases can/will adopt over time.

I want to find the time to write a blog post about this, I think it’s a pretty handy pattern.


>Linting in essence should be orthogonal to development

I guess that's what I disagree with. Yes, it adds complexity of its own, just like types do. And I still favor solutions that are based on types for most things, but more and more I try to go this route. They are surprisingly easy to write.


I think they have custom rules in the works, using `trustfall` query engine and yaml definitions

https://github.com/oxc-project/oxc/tree/main/crates/oxc_quer...


Trustfall queries are also how the Rust semver linter `cargo-semver-checks` works. It's cool to see more projects putting it the engine to good use!

I'm the Trustfall maintainer, happy to answer questions about the query engine or how oxlint or cargo-semver-checks use it.

I also recently gave a talk at P99 CONF on how cargo-semver-checks used Trustfall's optimizations API to get a 2000x speedup: https://www.youtube.com/watch?v=Fqo8r4bInsk


Isn’t that an NPM/Node thing? I mean I sometimes look at two React Native projects and a web project. The dependency situation there is downright anxiety inducing and that I am saying as an Android developer so please know that I am kind acquainted with dependency mess.


Not only that, but you also need deps to get eslint to support your specific flavour of pre-transpiled JS. Not only typescript, but new standard JS syntax (like ?. or ??) often requires updating the eslint parser.


I'm not sure there's a way around that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: