[HN Gopher] Rome: A Linter for JavaScript and TypeScript
___________________________________________________________________
Rome: A Linter for JavaScript and TypeScript
Author : acemarke
Score : 46 points
Date : 2020-08-08 19:27 UTC (3 hours ago)
(HTM) web link (romefrontend.dev)
(TXT) w3m dump (romefrontend.dev)
| swyx wrote:
| the prevailing consensus esp in the JS world is that 1 tool
| should do 1 thing. This is fine under the Unix philosophy, but
| challenges arise due to the combinatorial explosion of config
| needs, bad errors, and overhead from crossing module boundaries.
| There are a number of attempts at challenging this status quo:
|
| - ESbuild (100x faster than webpack in part due to focus on doing
| a single parse (but also shipping a Go binary))
|
| - Deno
|
| - Rome
|
| As we consolidate on the jobs to be done we expect out of modern
| tooling, it makes sense to do all these in a single pass with
| coherent tooling. It will not make sense for a large swathe of
| legacy setups, but once these tools are battle tested, they would
| be my clear choice for greenfield projects.
|
| recommended related reads:
|
| - https://medium.com/@Rich_Harris/small-modules-it-s-not-quite...
|
| - (mine) https://www.swyx.io/writing/js-third-age/
| Konohamaru wrote:
| Ugh. I cannot stand names based on ancient things or myths. They
| remind me of the early days of programming when systems were
| named Neptune, Iapetos, or Cronus in order to make themselves
| sound bigger or larger than life.
| Vinnl wrote:
| Sebastian keeps mentioning how all these different kind of tools
| could re-use the same infrastructure for the things they all do,
| but... It's still not quite clear to me what benefit that brings
| to me as a non-contributor? I can see how it could be beneficial
| if the entire ecosystem would rally around the same tools and
| then be able to move faster, but given that that has not yet
| happened... Why would I use this to lint my code? The nicer error
| messages?
| _greim_ wrote:
| I'm not an expert in the internals of these things, but
| presumably Prettier, Webpack, TypeScript, Babel, Istanbul, and
| ESLint each build their own separate, private ASTs from
| scratch. Maybe a project like this could pipeline a sequence of
| ASTs one to the next, and skip some of that overhead?
| acemarke wrote:
| Two immediate potential benefits:
|
| - Only one tool to configure, instead of many
|
| - Many tools revolve around parsing your code and generating an
| AST, then manipulating / processing that AST (Prettier, ESLint,
| Babel, TS, Webpack, ....). That's a lot of extra processing
| that has to be done. In theory, doing all that processing
| _once_, and reusing the AST, would potentially run a lot
| faster.
| k__ wrote:
| Also, fixes in the shared libs would be directly available to
| the tools build on top.
| Jarred wrote:
| I don't work on Rome and haven't looked at their code much, but
| if I were to guess: performance and better error messages
|
| If you can do the same work in fewer passes, it will often be
| faster
|
| So instead of every file change, webpack runs its own parser,
| then Babel runs its own parser, then ESLint, etc -- Rome
| probably just runs the parser once and sends the AST to other
| plugins
|
| And then if you invest in making the parsing stuff really good,
| that makes the linter better, the Babel-equivalent better, etc
| topicseed wrote:
| Huge ambitious project and I hope it delivers. If anyone can lead
| this one to fruition is Sebastian. So this project is in good
| hands.
|
| Undeniably, it's technically ambitious to build all these pieces
| under a single umbrella. And then, convincing people who are
| honestly scared to touch their Webpack config to switch to a new
| tool might not be easier.
|
| But if Rome booms, it'll truly benefit the community.
___________________________________________________________________
(page generated 2020-08-08 23:00 UTC)