13 ms·
Rome: A Linter for JavaScript and TypeScript
- Vinnl 6y agoSebastian 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?
- acemarke 6y agoTwo 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__ 6y agoAlso, fixes in the shared libs would be directly available to the tools build on top.
- Jarred 6y agoI 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
- _greim_ 6y agoI'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?
- Vinnl 6y agoThanks for the answers everyone. Just wanted to point out this comment by Sebastian that also perfectly explains it: https://news.ycombinator.com/item?id=24096744 https://news.ycombinator.com/item?id=24096744 (And it would be good to put something to that extent prominently on the website, if it isn't yet.)
- topicseed 6y agoHuge 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.
- Aeolun 6y ago> convincing people who are honestly scared to touch their Webpack config to switch to a new tool might not be easier. If someone can offer me a convincing alternative to webpack I will switch in a heartbeat.
- topicseed 6y agoSame, but the whole point is to switch you away from Webpack, Eslint, Prettier, Jest... I truly hate Webpack, but I do love Jest. Basically, Rome will most likely need somewhat of a Typescript moment. Where it's just transitioning to the new normal for (many) JS projects.
- schwartzworld 6y agoParcel is pretty amazing
- wecryopen 6y agoagree 100%. love how it requires no configuration.
- WorldMaker 6y agoI'm almost convinced by snowpack, especially because it has an escape hatch to webpack. (But that escape hatch is of course yet another opaquely managed webpack config, so hence some of the remaining reservations.)
- swyx 6y agothe 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-that-simple-3ca532d65de4 https://medium.com/@Rich_Harris/small-modules-it-s-not-quite... - (mine) https://www.swyx.io/writing/js-third-age/ https://www.swyx.io/writing/js-third-age/
- throwaway894345 6y agoMan, the performance benchmarks that esbuild publishes are pretty remarkable. I know it's common to cherry-pick favorable benchmarks, but even if these are misleading by two orders of magnitude esbuild would be best in class.
- esperent 6y agoI also found them unbelievable so I did some quick tests with a couple of large projects that I'm working on, currently using Rollup. From these, I'd say their benchmarks are completely accurate.
- tonyhb 6y agoAgree. I went as far as regressing to `watchexec` to re-run esbuild and cargo build on any changes. Esbuild is near instant compared to anything else.
- amasad 6y agoI wrote about something related as well: Disintegrated Development Environments — How Did We Get Here? https://amasad.me/disintegrated https://amasad.me/disintegrated
- Konohamaru 6y agoUgh. 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.
- tln 6y agoI like the name. It evokes "all roads lead to Rome" Although "Borg" might be more accurate.
- moogly 6y agoI thought it was a reference to "Rome wasn't built in one day". As in, the creators know that this is one hell of an ambitious project.
- RobertKerans 6y ago"All roads lead to Rome" is the reference
- sebastianmck 6y agoIt's both.
- ironmagma 6y agoAnd what’s wrong with the early days? Great things were accomplished back then.
- elondaits 6y agoRome is the current capital of Italy... not a mythical or ancient thing.
- Konohamaru 6y agoRoma is the current capital of Italy. Rome was an ancient city.
- rubber_duck 6y agoWhy start this from scratch ? Why not build on top of TypeScript ? I get the single pass rationale but isn't it possible to integrate a bundler into TypeScript compiler ? I'm just wondering because Microsoft has a decently sized team of paid engineers working on TS for years now - what are the odds an OSS project outperforms them at implementing their own language (which they also evolve with every release)
- wolfgang42 6y agoThe TypeScript compiler API[1] is beta, underdocumented, and not really designed to support use-cases other than working with an abstract AST. It’s OK for transpiling, but would be a bit awkward for writing a linter and not at all suitable for a formatter. As an example of the sort of problems you might run into with the API in its current state, trying to parse and then pretty-print code can cause comments to vanish[2] under certain circumstances. This is fine for transpiling, but is a major issue when you’re trying to prettify and overwrite the original source file. [1] https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API https://github.com/Microsoft/TypeScript/wiki/Using-the-Compi... [2] https://github.com/microsoft/TypeScript/issues/39620 https://github.com/microsoft/TypeScript/issues/39620
- rubber_duck 6y agoI get that - but since TS is also OSS you can fork and upstream, still sounds like less work than writing everything from scratch.
- wolfgang42 6y agoSure, but they may well have looked at the state of it and concluded that it would need to be rewritten to get it to do what they needed—in which case doing that in a new project is actually less effort, since you don’t need to support the existing uses. (I agree it’d be interesting to hear from the creators, since this is a somewhat unusual result.)
- rmthw 6y ago
- rattray 6y agoI feel so torn on this project. On the one hand, I want to root for sebmarkbage, who has done so much for the field. On the other, as someone who used to do some "JS platform" work at a tech company, I really don't want Rome to catch on. Yet Another Standard is really painful for the ecosystem, and while it's obnoxious that you need so many tools, at least we've finally settled (mostly) on good answers for each vertical. TS, ESlint, Prettier, Webpack, Babel. Now, would it be nice if there were an underlying engine/server that all tools could use to share an AST without reparsing everything? Sure, I guess. Would it also be nice to have one tool that wraps the others, at least when you're getting started? Yes, though I think create-react-app has blazed that trail pretty well. The thing is, all those tiny little details from Prettier and ESLint and Webpack really matter – Rome will take years to achieve the number of lints that ESLint has, and even more years for the community to agree on which ones matter. Similarly, every corner-case of prettifying will have to be considered anew, and every edge case of bundling rebuilt or reimagined. I love to see a talented person take on something insanely ambitious, so I wish him luck and hope he proves me wrong. But if Rome succeeds, it'll be a big pain for a lot of people as they try to port everything over, and for the community as they grapple with dueling standards for how things should be done.
- sebastianmck 6y agoThe ecosystem is already fragmented and dueling. When it says it replaces those tools it means it aims to replace the functionality of those tools, not make them obsolete. Rome being successful doesn't mean eliminating those tools, it's providing something valuable and giving people an option. If it's not for you then that's okay. Rome is early and is still evolving, including possible areas for extensibility. I think a lot of people don't realize the sort of capabilities that they're missing out on by not having their tools work together, or sticking with old tooling that cannot innovate for legacy reasons (like Babel). I don't think it's harmful to the ecosystem to advocate for more consolidation, especially around tooling that not a lot of people either like to deal with, or have few maintainers in the first place. I also think you have me (Sebastian McKenzie) confused with Sebastian Markbage from the React team.
- streptomycin 6y ago
- marmada 6y agoThere's something that scares me about Rome: it's lack of plugins. I really like Babel because of its plugins. My project typecheck.macro, could not exist without Babel plugins. How will Rome support compile time transformations like graphql.macro or typecheck.macro? Compile time plugins allow JavaScript to evolve super rapidly & make the creation of frameworks that act as compilers instead of traditional frameworks possible. [1] https://github.com/vedantroy/typecheck.macro https://github.com/vedantroy/typecheck.macro
- ricardobeat 6y agoThey are not the same thing. Despite not supporting plugins, I think you can definitely expect Rome to support some form of macros, thought it might look different from the existing API in babel.
- sebastianmck 6y agoI spoke in this post about how rushing into a plugin system hurt the longevity of Babel and it's ability to innovate. We aren't going to make the same mistake again. Rome will likely eventually have a plugin system, but what that would look like isn't clear. This is the first release and until there's some actual usage, there's no real way to realistically predict what sort of things people will feel is missing. You can always supplement your project with multiple linters if you feel like it is currently a blocker.
- spankalee 6y agoWithout plugins at first, how open are you to contributions that would normally go into a plugin and not into core? As someone who works on libraries that don't use JSX, and therefore have to rely on compiler and linter plugins to get support (tagged template literals in my case) I worry that React's dominance will mean that it gets a place in Rome, while other systems are locked out, which only increases React's dominance. Would you consider an internal plugin system as a first step, where plugins have to be part of the codebase, but intentionally get a restricted API surface? This would allow you to try out and refactor the plugin API over time before committing to it publicly.
- sdwvit 6y agoBut why?
- sjroot 6y agoThat’s the same question I had when I read your comment!
- wildpeaks 6y agoA few questions on top of my head when I consider changing the toolchain: - does it handle images imports - does it handle scss imports - if not, does it require css-in-js (and if so which one) - does it handle shaders imports (and other arbitrary dependencies that need custom processing to get embedded in the bundle) - does it generate SRI hashes for stylesheets and scripts - can it generate web workers - can it generate node bundles or only browser bundles - can it split chunks - do you still get TS intellisense in VSCode - can it be used with Rust and/or Webassembly
- sebastianmck 6y agoIt's a linter so you don't need to ask any of those questions. Future usage as a bundler isn't dependent on any decision to use it as a linter.
- deleted 6y ago[deleted]
- wildpeaks 6y agoIt does matter if the only value of the linter at the moment is that it will be part of a set of tools to replace the entire toolchain. It already took forever for the ecosystem to get JSHint, Tslint and others to converge into Eslint.
- iRomain 6y agoWhy a focus on frontend only? I am using Typescript, Babel, Jest and a bundler for any app/library on the frontend/backend. If you got to do it, do it all the way! I can already see the GH issues, “sorry, this is a backend use case”. So now my tooling would end up being more complex with the addition of another tool since it will never support all my use cases. Seemed promising but this alone makes me question its utility.
- novaleaf 6y agoI just last week found out about https://rushstack.io/ https://rushstack.io/ you might like it.
- no_wizard 6y agoI think this has a brighter future than lerna if you are managing a monorepo They’re betting big on PNPM being a strong long term bet. They also just recently released Heft which is the rushstack repo build/lint/dev-server stack. It’s a promising project
- novaleaf 6y agototally agree, on all counts. I'm getting back into typescript dev and tried lerna... I couldnt get it working after a week of trying. It probably does work, just lack of tutorials makes it a really steep learning curve. Then I found an out-of-passing mention to Rush and !!! Heft is great. PNPM is great (hadn't known about that either)
- sebastianmck 6y agoTypeScript is a frontend language. "Frontend" is the category of languages we plan on supporting. It doesn't say anything about your usage of those languages. Where you run the code does not matter.
- capableweb 6y agoCould you expand on why you think TypeScript is a "front-end" language? I was under the impression that it just compiles to Javascript and while Javascript used to be a front-end language, it's nowadays bravely used for backend projects as well, for some reason.
- smhmd 6y agoI liked the old logo[0] better. [0]: https://raw.githubusercontent.com/romefrontend/rome/1d58305097f768b320150bb9bd293c7e74f87b00/assets/logo_with_text.png https://raw.githubusercontent.com/romefrontend/rome/1d583050... [1]: https://raw.githubusercontent.com/romefrontend/rome/main/assets/JPG/logo.jpg https://raw.githubusercontent.com/romefrontend/rome/main/ass...
- Aeolun 6y agoI was sure I’d heard of this before, but it looked different. I guess that is why.
- tbeseda 6y agoThat helmet is Greek. It was a placeholder. There's a pretty good GH issue[0] for creating the new one. [0]: https://github.com/romefrontend/rome/issues/1 https://github.com/romefrontend/rome/issues/1
- LibertyBeta 6y agoI find this interesting. One of the things I like about languages like Go, Dart, and Rust is their robust tooling.
- namelosw 6y agoIs there any chance that Rome can be based on Deno in the future? It seems to me Deno has built with browser-like environments in mind, thus the environment would be more unified. Node.js is pretty much a different beast. If we want to have an ambitious project like Rome, I would love to have it based on an ambitious foundation.
- ARussell 6y agoI asked this question, as well, and the answer I got is that Deno already does these things.
- yoav 6y agoI’m not great at predicting how tech will evolve but I have a feeling that this will be built in a day.
- toohotatopic 6y ago>Regular double quoted strings can have newlines. This doesn't feel right. There are already ` for multi-line comments. Why not use them? Changing the meaning of " breaks the ability to copy paste an rjson file into regular sourcecode.
- no_wizard 6y agoI feel like Google could have had this with their Closure Compiler/Sheets/Templates/Library but they never dedicated any resources to making the APIs more ergonomic and they’ve been historically poorly documented as well, not to mention for one reason or another the Compiler doesn’t do automatic dependency traversal and because the APIs are not not intuitive and well documented they lost mindshare. Like many great Google projects it just never got fully realized, which is a shame :(
- bsimpson 6y agoClosure's Achilles' heel is that it's written in Java. It's well-integrated into the stack at Google, but independent JS developers are often skeptical of tools that require more than `npm install`. It's been recently cross-compiler to JavaScript, so it is now available via npm.
- tobr 6y agoVery happy to see that this is no longer a Facebook project, which I believe it was just a few months ago. I’d bet there’s a good story behind that. Let’s liberate React next?
- bsimpson 6y agoSebastian started it, and it followed him when he left: https://romefrontend.dev/blog/2020/08/08/introducing-rome.html#history https://romefrontend.dev/blog/2020/08/08/introducing-rome.ht...
- SergeAx 6y agoStrangely there's no reference to XKCD yet. Here you go: https://xkcd.com/927/ https://xkcd.com/927/
- forty 6y agoPlease integrate the features of dependency cruiser [1] while you are at it. One of the most useful tool of its kind. [1] https://www.npmjs.com/package/dependency-cruiser https://www.npmjs.com/package/dependency-cruiser
- dandare 6y agoCan someone ELI5 what kind of linting is required for a transcribed code generated by TS compiler?
- draw_down 6y agoCome on
- draw_down 6y agoI like this idea, I’m tired of configuring tools that I use together to know about one another. I don’t need most of the notional power that arrangement supposedly can offer, and configuring these tools has only gotten more bewildering. Tired of screwing around with an endless array of plugins. Many of us build react apps, I think it’s worth having a toolchain that caters to that. I care a lot more about dev experience and speed than “one tool to do one job”. The “job” is to handle the code I’m working with in a way that isn’t as frustrating as our current tools.
- swimmingly 6y agoI just don't see the use case for RomeJS and I'm not sure people will want to wait several years for this project to mature. esbuild seems to hit the sweet spot for ESNext/TS/JSX/bundling - it's 100 times faster than current tooling and works today with with next to no configuration.
- userSumo 6y agoCan I ask how long is it probably going to take for Rome to provide fuctionality to replace the tools it aims to replace, in a stable release? Rough estimate
- satvikpendem 6y agoI feel like new tools for JS should ideally be written in a compiled language like Rust, just the performance benefits alone are making me use SWC rather than some other tools for part of my TypeScript toolchain.
- readarticle 6y agoThat was part of the impetus behind ReasonML IIRC, JS tooling in OCaml-ish. Not sure if the performance benefits translated though.
- satvikpendem 6y agoI use ReasonML a bit, but I don't think the comparison is exactly the same as I'm saying. ReasonML has JS like tools, such as esy in place of npm. I'm saying JS tools should be make in languages like ReasonML or Rust: fast, efficient, compiled languages.
- scns 6y agoThey absolutely did. Compilation happens in a fraction of a second, it is fun to use. Refrain if you have to use Typescript at work, it will spare you a lot of frustration.
- ausjke 6y agoHave been watching Rome for a while and can not wait to use it, especially since it's beta time. It took forever to get eslint/prettier/webpack etc to work in sync and if there is one tool can do it all, I'm all for it.