13 ms·
Oxlint – JavaScript linter written in Rust
- austin-cheney 3y agoIt 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.
- kristiandupont 3y agoThis 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.
- WhitneyLand 3y agoNot 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.
- bakkoting 3y agoeslint 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.
- kristiandupont 3y ago>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.
- jitl 3y agoI 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.
- DanielHB 3y agoNot 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.
- robertlagrant 3y agoI'm not sure there's a way around that.
- dm33tri 3y agoI 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_query https://github.com/oxc-project/oxc/tree/main/crates/oxc_quer...
- obi1kenobi 3y agoTrustfall 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 https://www.youtube.com/watch?v=Fqo8r4bInsk
- crossroadsguy 3y agoIsn’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.
- frou_dh 3y ago"ruff" for Python which is displacing the flake8 linter (and in fact the "black" code formatter too) shows that this kind of thing can work fantastically well.
- drexlspivey 3y agoI am hoping that ruff goes after type checking next to replace mypy which is pretty slow. One tool to rule them all
- VeejayRampay 3y agothey've successfully replace pylama and black so yeah I really hope it's their next target (though handling types is a whole different beast altogether)
- C-Saunders 3y agoHave you checked out Pyright[1]? It's not one tool to rule then all, but it is nice and fast. [1]https://github.com/microsoft/pyright https://github.com/microsoft/pyright
- sztomi 3y agoPyright is neat but the CLI output makes me want to poke my eyes.
- imron 3y agodmypy [0] (installed when you install mypy) will give you a x10 speedup when running mypy after small regular edits (e.g. during general development). But yeah, I'm also looking forward to the day when I only need a single speedy tool for python linting, type-checking and formatting. 0: https://mypy.readthedocs.io/en/stable/mypy_daemon.html https://mypy.readthedocs.io/en/stable/mypy_daemon.html
- simicd 3y agoHave you by any chance used Pyright? If not, I can highly recommend it. The VS Code extension makes writing Python almost as if it's a statically typed language (+ there is a CLI if you want to check types in CI). The docs are claiming that it's 3-5x faster than mypy - I haven't run performance benchmarks myself, all I can say is that for all my code bases it is very fast after the first cold start. Comparison to mypy: https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/main/docs/mypy-com...
- deleted 3y ago[deleted]
- Alifatisk 3y agoDid anyone notice? We now have 5 different ways to install this package.
- deleted 3y ago[deleted]
- Waterluvian 3y agoI want to complain but this richness in developer availability to implement the same thing many times is why we get a linter that’s 100x faster or a webpack alternative that’s 50x faster.
- jussij 3y agoSo, which one of those five options is the simple download?
- Alifatisk 3y agoI’d go with pnpm
- thiht 3y agoSo? You don’t have to use, or even know all five.
- conartist6 3y agoSure, but if you don't know what all the ways are you'll be prone to "just follow instructions" and you may not notice that a few years apart your followed instructions regarding different ways of installing or uninstalling things and now your system is a mess
- ramon156 3y agoI can't fathom why you would argue availability is bad. You're right about keeping things implicit for devs, but if all five work I don't see an issue
- lloydatkinson 3y agoThis can only be good news. Normally I, like anyone else experienced with the JS ecosystem, despair when new tools come out like this. However, consider: - setting up eslint isn't actually that simple - if you're using typescript you need eslint-typescript too - there are sets of rules in both eslint and eslint-typescript that conflict with each other, so I have countless rules in my config like this: 'comma-dangle': 'off', '@typescript-eslint/comma-dangle': ['error', 'always-multiline'], - then if you're doing React there's another set of JS and TS rules to apply, I still never figured out how to correctly apply airbnb rules - this is a pretty garbage developer experience - you can quite literally spend hours or days getting a "good" linting/formatting configuration setup, and you often can only use pieces of the configs you wrote for other repos because over time the rules and settings seem to change - I hope this will eventually support things such as .astro files which is actually a combination of TypeScript and TSX blocks > At this stage, oxlint is not intended to fully replace ESLint; it serves as an enhancement when ESLint's slowness becomes a bottleneck in your workflow. I also hope that eventually it does become a full replacement. I like eslint, but holy shit, I cannot bring myself to create a new config from scratch that wrestles all the required extras and the frequently changing dependencies. Also, wanted to give a sort of shout out to Deno here. Deno comes with a linter/formatter built in that is barely configurable (just double vs single quote, 2 or 4 space indentation, minor things) and it too is very fast and simply "just works". --- Update: I just gave it a quick try and I am immediately impressed by it. Not only was it incredibly fast like it claims, it appears to already have all of the rules I was complaining about built in. eslint-plugin-react(jsx-no-useless-fragment): Fragments should contain more than one child. ╭─[src/design/site/preact/MobileNavigationMenu.tsx:18:1] 18 │ return ( 19 │ <> · ── 20 │ <MenuButton isOpen={isOpen} onChange={setIsOpen} /> Finished in 17ms on 90 files with 70 rules using 16 threads. Found 13 warnings and 0 errors.
- ahuth 3y agoI am defending eslint/JS's honor in other replies, but you're right... setting up eslint is too complicated (and more complicated in TS).
- c-hendricks 3y ago
- Aissen 3y ago> 50-100 Times Faster than ESLint > Our previous linting setup took 75 minutes to run, so we were fanning it out across 40+ workers in CI. By comparison, oxlint takes around 10 seconds to lint the same codebase on a single worker[…] So it's in fact 18000 times faster on this embarrassingly parallel problem (but doing less for now).
- joeldo 3y ago75 / (1/6) = 450. Still very exciting!
- Aissen 3y agoYou forgot the 40 workers vs 1 worker.
- anamexis 3y agoThe way I read it, it was taking that amount of time before they split it into workers.
- rwilsonperkin 3y agoCorrect, it was 75 minutes total compute time. That was spread across workers to make the walltime more reasonable
- Aissen 3y agoIndeed, I really need to improve my reading comprehension.
- msoad 3y agoin a very large codebase, how common it is to run the linter for the entire repo? Is this an optimization worth spending time on?
- 3y ago
- pjmlp 3y ago[flagged]
- kajaktum 3y agoIt has always been possible to do this kind of things (we have C, C++, Java) but I don't think people have been this semi-successful with reimplementing a bunch of common tools. Where are all the X re-implemented in C/C++/Java?
- pjmlp 3y agoUsually a matter of skill, most likely.
- afavour 3y ago> Maybe one shouldn't have started writting all those tools in JS in first place. Sure but rather than scold people perhaps we should examine why they used JS instead of a compiled language. And why that’s changed now.
- shzhdbi09gv8ioi 3y agoWhen all you have is a hammer, everything is a nail. We know why js devs chose js already. We also know some of them learned rust and used their new hammer to bang out better solutions. See OP :)
- afavour 3y ago> When all you have is a hammer, everything is a nail. But it was possible to write C/C++ modules for Node very early on. So there were always multiple hammers available.
- ahuth 3y agoSure, for some tools. Most the time it's fine, though. It's also nice that people in the JS community can easily contribute to tools written in JS (including writing custom eslint rules).
- d3w4s9 3y ago> it serves as an enhancement when ESLint's slowness becomes a bottleneck in your workflow Well, when I need to batch fix errors in files, yes it can take a while to run eslint. But that almost never happens. I have the plugin and fix errors as I go (which I believe is what most people do), and I never feel performance is an issue in this workflow. I really doubt how (actually) useful this is.
- jcelerier 3y agoIt's still using more battery
- d3w4s9 3y agoTrue, but eslint energy use would be one of the last things I worry about if I am looking for a longer battery life. Chances are that TypeScript service used for Intellisense costs more electricity.
- sapiogram 3y agoTheir main motivation seems to be CI, where people often lint the entire repo on every PR.
- msoad 3y agowhich is a really weird problem to have. Only lint files that have changed? How hard that is? our monorepo is 3m lines of code and running lint is not a bottleneck by any means... And once in a while that we have to run lint for entire repo (ESLint upgrade for example) we can afford to wait 1 hour ONCE
- Aeolos 3y ago50-100x faster would turn that 1 hour into 1 minute. It's not that you can't wait 1 hour, it's that you don't have to wait. Think of all the wasted cycles that could be put to better use...
- ForkMeOnTinder 3y ago
- silverwind 3y agoLikely not worth using currently as it only has like 200 rules, while typical eslint setups have 600 or more.
- deleted 3y ago[deleted]
- leipert 3y agoWhy not run both? Run the 200 rules from this one and the 400 other rules with eslint.
- recursive 3y agoNow you have 2 problems.
- lakpan 3y agoI don’t think that’s practical at all. IMO oxlint currently only fits the niche “I’m starting a new project and I don’t want to install 100 dependencies and configure eslint”. Without ts-eslint and unicorn rules this is DOA for me otherwise (but I’m hopeful)
- pzmarzly 3y agoIf I understand it right, we have 3 large projects that aim to replace most of JS tools on their own: Bun[0], Oxc[1] and Biome[2]. Bun's package manager is great, Biome formatter recently reached 96% compatibility with Prettier, and now Oxlint is apparently good enough to replace ESLint at Shopify. Exciting times ahead. But it's giving the impression that these projects perhaps could be better off collaborating instead of each of them aiming to eat the world on their own? EDIT: I'm not saying it's wrong to write competing tools, it's open source anyway, so please do whatever you like with your time and have fun. But it looks like out of these 3 projects, 1 has a startup behind it, and 1 receives funding from bigger company. I assume that money will stop coming in if these tools don't gain adoption fast enough, and nobody would want to see that happen, especially with so much potential here. [0] https://bun.sh/ https://bun.sh/ [1] https://oxc-project.github.io/ https://oxc-project.github.io/ [2] https://biomejs.dev/ https://biomejs.dev/
- djbusby 3y agoHappens loads of times. There is some in-built human condition that folk basically see a thing that they could improve but then decide to go off and build their own moon-base rather than work on someone elses project.
- throwaway894345 3y agoIn my experience, project maintainers are frequently uninterested in changes to their project, especially if those changes are a significant departure from their current vision or if it involves pivoting away from tools that they like. You're often expected to make years of contributions to the project to earn the rapport to bring significant suggestions before the maintainers. It's often just easier to 'build your own moonbase' instead of politicking. Just a couple days ago, the curl maintainer published a blog post about why he wouldn't rewrite curl in Rust and a big part of the reason was that he and the other maintainers weren't good at it and weren't the right people to lead a project that used it--he said that he encouraged other people to start their own project in Rust. But then when people follow that advise, they're chided for not contributing to the more established project! To be clear, I'm not a "just rewrite it in Rust" guy, but I think people underestimate the difficulty and frustration involved in petitioning an established project to make the reforms necessary for significant improvements.
- art0rz 3y agoI would really like to speed up my workflow with a faster ESLint alternative, but my ESLint configs are often very customized, with rules and plugins that are not available (yet) in the alternative solutions, making them a non-starter for me. It'll take a while for these alternatives to reach plugin/rule parity.
- maccard 3y agoWould you consider removing your customisations to be closer to the workflows supported by these tools? One of the great things about go is that you're free to have an opinion, but if you disagree with go fmt or go build, your opinion is wrong.
- art0rz 3y agoNo. A linter does more than formatting. Besides, some rules may simply not be relevant to what I'm working on while other rules are. Prettier works well enough for most people because it only covers syntax, and not whether or not you can use await in a loop, or should add tracks to your video element, or if jsx should be in scope, etc.
- bsnnkv 3y agoThis is one of the real productivity superpowers of ecosystems like Go and Rust imo
- IshKebab 3y agoPython and JavaScript have similarly good formatters (as long as your idiot colleagues don't insist on using yapf instead of Black, despite yapf producing non-deterministic output!). In fact I would say Rust is probably behind Prettier in terms of auto formatting. The rustfmt output is less pretty (subjective I know), the devs have made several strange decisions and it seems to be semi-abandoned (maybe partly because the devs were ... shall we say not as friendly and welcoming as the Rust community likes to bleat on about). There are a couple of alternative formatters: * https://github.com/andrewbaxter/genemichaels https://github.com/andrewbaxter/genemichaels * https://github.com/jinxdash/prettier-plugin-rust https://github.com/jinxdash/prettier-plugin-rust Still, all of them are better than clang-format!
- klageveen 3y agoThis is cool of course. But so was Rome. Which only existed for about two years. It’s one thing to build a cool tool, it’s something else entirely sustain one over time. I need a bit more proof that this is sustainable before I rebuild our toolchain, _again_.
- lucideer 3y agoThe spate of rewrites of JS tools in compiled languages continues. Here's my problems with them: 1. The need for a 50-100x perf bump is indicative of average projects reaching a level of complexity and abstraction that's statistically likely to be tech debt. This community needs complexity analysis tools (and performant alternative libraries) more than it needs accelerated parsers that sweep the complexity problem under a rug. 2. (more oft cited) The most commonly and deeply understood language in any language community is that language. By extension, any tools written in that language are going to be considerably more accessible for a broader range of would be contributors. Learning new languages is cool but diverging on language choices for core language tooling is a recipe for maintainer burnout.
- rafaelmn 3y agoHow often does an average X developer delve down to compiler details and contribute to static analysis tooling ? Metaprogramming and compilers/language analysis tooling is a jump above your run of the mill frontend code or CRUD backends. Sort of elitist, but IMO devs capable of tackling that complexity level won't be hindered by a different language much. And Rust is really tame compared say C/C++. Borrow checker is a PITA, but it's also really good at providing guardrails in the manual memory management land, and the build tooling is really good. Don't know enough about Zig but I get the impression that rust guardrails would help developers without C/C++ background contribute safe code. You could argue Go is an alternative for this use case (and similar languages) but it brings it's own runtime/GC, which complicates things significantly when you're dealing with multi language projects. There's real value in having simple C FFI and minimal dependencies.
- lucideer 3y ago> Sort of elitist, but IMO devs capable of tackling that complexity level won't be hindered by a different language much. Not elitism, just an honest appraisal, though I think flawed as competency isn't linear it's heterogeneous - you'll find the most surprising limitations accompanying the most monumental talent. Language fixation is a common enough one, but even beyond that, the beginner-expert curve on each language shouldn't be underestimated regardless of talent or experience. In particular when it comes to Javascript there's a tendency to believe the above by virtue of the community being very large & accessible - bringing in a lot of in-expert contributors, especially from the web design field. This isn't fully representative of the whole though: there are significant solid minorities of hard JS experts in most areas.
- WhereIsTheTruth 3y agoI would be surprised and worried if a native tool would be slower than a javascript one, even with JIT, wich is useless for short lived programs
- msoad 3y agoThis is HackerNews so brace for criticism! Why would a team of talented engineers focus on solving ESLint performance issue? Where is the value in this? If your project is small, ESLint is fast enough. If it's super large like ours (3 millions LOC) then you spend a little time making local and CI linters smarter to run only on changed files. Rewriting in Rust seems cool and novel but now you lost the entire wealth of ESLint plugin ecosystem, you have to keep up with maintaining this new linter which has to be updated very frequently for at least new syntaxes and so on... We could put this effort into looking into why ESLint is not fast enough and fix the bottlenecks IF we had extra time in our hand... If it was my team, I would not let them spend time on this. I don't see the value to be honest.
- Trufa 3y agoThey developed a new tool that reduces their CI from 75 minutes to 10 seconds and are offering it for free and open source and you really don’t see the value? I know you warned this is HN but I find this posture ridiculous. If you don’t find value for yourself, that’s one thing but I honestly don’t get this place sometimes.
- msoad 3y agoI'm not complaining about free software offered to world for free. I'm curious how a leader would justify an investment like this? I have engineers reaching to me and asking me to all sort of things. My job is to justify it for the business. Making this costs more than a million dollar if their engineers are paid like ours. Then how you do this? How do you get budget for this?
- kbknapp 3y agoI'm not a fan of trying to put hard numbers on unknowns like this because it biases against uncertainty, but if they shaved ~74 minutes off their CI time and assuming it runs multiple times a day that very quick equates to a small teams cost savings over a year. However, I think trying to find the actual numbers is dumb because there's also the intangibles such as marketing and brand recognition bump by doing this both for the company and individuals involved. That's not to say all greenfield endeavors should be actioned, but ones with substantial gains like this seem fine given the company is big enough to absorb the initial up front cost of development.
- thatxliner 3y agoI don’t understand how this is better than Biome. Does it support more rules than Biome?
- romanhotsiy 3y agoCompatibility with eslint. They implement the most common eslint rules and looks like esling config support is WIP.
- conaclos 3y agoBiome implements more ESLint rules than OXC: Biome implements about 90 ESLint rules [0], while OXC implements about 60 rules. This brings Biome closer to parity with ESLint. However, Biome has changed some rule names, uses camel-case rule names instead of kebab-case names, doesn't provide some rule configurations (to avoid configuration nightmares), and slightly changes some rule behavior (as OCV does). [0] https://github.com/biomejs/biome/discussions/3 https://github.com/biomejs/biome/discussions/3
- deleted 3y ago[deleted]
- hexmiles 3y agoSay what you want about the "rewrite in rust" meme, but it really seems that rust started a trend of really caring about performance in everyday tools.
- deleted 3y ago[deleted]
- bfrog 3y agoI think its amazing that all these tools being rewritten in rust are likely being done by people that likely do not typically code in C/C++ but did code something like this in rust. To be that says Rust is more easily accessible as a language than C/C++ and that's great for our environment (speed is green) and our joy in computing (speed is happiness).
- ku1ik 3y agoThis.
- AntonCTO 3y agoI'd like to highlight dprint [0]. It is not as opinionated as Prettier, and its AST-node-specific configuration is awesome [1]. Deno uses it under the hood for `deno fmt` (and switched from Prettier [2]), and the TypeScript team uses it for formatting their code base (switched from formatting by ESLint [3]). [0] https://dprint.dev/ https://dprint.dev/ [1] https://dprint.dev/plugins/typescript/config/ https://dprint.dev/plugins/typescript/config/ [2] https://github.com/denoland/deno/issues/3818 https://github.com/denoland/deno/issues/3818 [3] https://github.com/microsoft/TypeScript/pull/54820 https://github.com/microsoft/TypeScript/pull/54820