TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Oxlint – JavaScript linter written in Rust

299 点作者 pritambarhate超过 1 年前

16 条评论

austin-cheney超过 1 年前
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.
评论 #38653429 未加载
评论 #38653519 未加载
评论 #38656099 未加载
评论 #38653482 未加载
art0rz超过 1 年前
I 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.
评论 #38654799 未加载
评论 #38654074 未加载
AntonCTO超过 1 年前
I&#x27;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]).<p>[0] <a href="https:&#x2F;&#x2F;dprint.dev&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;dprint.dev&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;dprint.dev&#x2F;plugins&#x2F;typescript&#x2F;config&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;dprint.dev&#x2F;plugins&#x2F;typescript&#x2F;config&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;3818">https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;3818</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;TypeScript&#x2F;pull&#x2F;54820">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;TypeScript&#x2F;pull&#x2F;54820</a>
Aissen超过 1 年前
&gt; 50-100 Times Faster than ESLint<p>&gt; 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[…]<p>So it&#x27;s in fact 18000 times faster on this embarrassingly parallel problem (but doing less for now).
评论 #38655054 未加载
评论 #38653789 未加载
评论 #38653815 未加载
评论 #38654341 未加载
评论 #38654118 未加载
lloydatkinson超过 1 年前
This 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:<p>- setting up eslint isn&#x27;t actually that simple<p>- if you&#x27;re using typescript you need eslint-typescript too<p>- 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:<p><pre><code> &#x27;comma-dangle&#x27;: &#x27;off&#x27;, &#x27;@typescript-eslint&#x2F;comma-dangle&#x27;: [&#x27;error&#x27;, &#x27;always-multiline&#x27;], </code></pre> - then if you&#x27;re doing React there&#x27;s another set of JS and TS rules to apply, I still never figured out how to correctly apply airbnb rules<p>- this is a pretty garbage developer experience<p>- you can quite literally spend hours or days getting a &quot;good&quot; linting&#x2F;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<p>- I hope this will eventually support things such as .astro files which is actually a combination of TypeScript and TSX blocks<p>&gt; At this stage, oxlint is not intended to fully replace ESLint; it serves as an enhancement when ESLint&#x27;s slowness becomes a bottleneck in your workflow.<p>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.<p>Also, wanted to give a sort of shout out to Deno here. Deno comes with a linter&#x2F;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 &quot;just works&quot;.<p>---<p>Update: I just gave it a quick try and I am <i>immediately</i> 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.<p><pre><code> eslint-plugin-react(jsx-no-useless-fragment): Fragments should contain more than one child. ╭─[src&#x2F;design&#x2F;site&#x2F;preact&#x2F;MobileNavigationMenu.tsx:18:1] 18 │ return ( 19 │ &lt;&gt; · ── 20 │ &lt;MenuButton isOpen={isOpen} onChange={setIsOpen} &#x2F;&gt; Finished in 17ms on 90 files with 70 rules using 16 threads. Found 13 warnings and 0 errors.</code></pre>
评论 #38653663 未加载
评论 #38653652 未加载
评论 #38669837 未加载
评论 #38654836 未加载
frou_dh超过 1 年前
&quot;ruff&quot; for Python which is displacing the flake8 linter (and in fact the &quot;black&quot; code formatter too) shows that this kind of thing can work fantastically well.
评论 #38653502 未加载
评论 #38654530 未加载
评论 #38653889 未加载
评论 #38654390 未加载
Alifatisk超过 1 年前
Did anyone notice? We now have 5 different ways to install this package.
评论 #38654547 未加载
评论 #38653574 未加载
评论 #38653760 未加载
评论 #38653535 未加载
评论 #38654034 未加载
thatxliner超过 1 年前
I don’t understand how this is better than Biome. Does it support more rules than Biome?
评论 #38654579 未加载
评论 #38654606 未加载
WhereIsTheTruth超过 1 年前
I 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
pzmarzly超过 1 年前
If 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&#x27;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.<p>But it&#x27;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?<p>EDIT: I&#x27;m not saying it&#x27;s wrong to write competing tools, it&#x27;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&#x27;t gain adoption fast enough, and nobody would want to see that happen, especially with so much potential here.<p>[0] <a href="https:&#x2F;&#x2F;bun.sh&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;bun.sh&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;oxc-project.github.io&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;oxc-project.github.io&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;biomejs.dev&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;biomejs.dev&#x2F;</a>
评论 #38654044 未加载
评论 #38653664 未加载
评论 #38654498 未加载
评论 #38653975 未加载
评论 #38653705 未加载
lucideer超过 1 年前
The spate of rewrites of JS tools in compiled languages continues. Here&#x27;s my problems with them:<p>1. The need for a 50-100x perf bump is indicative of average projects reaching a level of complexity and abstraction that&#x27;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.<p>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.
评论 #38654192 未加载
评论 #38654076 未加载
评论 #38654130 未加载
评论 #38654099 未加载
评论 #38654335 未加载
d3w4s9超过 1 年前
&gt; it serves as an enhancement when ESLint&#x27;s slowness becomes a bottleneck in your workflow<p>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.
评论 #38653953 未加载
评论 #38653731 未加载
评论 #38654671 未加载
评论 #38654629 未加载
silverwind超过 1 年前
Likely not worth using currently as it only has like 200 rules, while typical eslint setups have 600 or more.
评论 #38656079 未加载
评论 #38654386 未加载
hexmiles超过 1 年前
Say what you want about the &quot;rewrite in rust&quot; meme, but it really seems that rust started a trend of really caring about performance in everyday tools.
评论 #38654663 未加载
评论 #38654603 未加载
msoad超过 1 年前
This is HackerNews so brace for criticism!<p>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&#x27;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...<p>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...<p>If it was my team, I would not let them spend time on this. I don&#x27;t see the value to be honest.
评论 #38654276 未加载
评论 #38654332 未加载
klageveen超过 1 年前
This 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_.
评论 #38653966 未加载