Live data from Hacker News

Rome: A Linter for JavaScript and TypeScript

romefrontend.dev

111–120 of 140 posts

Re: Rome: A Linter for JavaScript and TypeScript

#111
post #13

I 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 verti…

I don't see it this way; I see Rome as the Apple of front-end tooling. You use an opinionated service to do most of the work. No brainer!

If you want more configuration, build your own, and most people will do. But for the novice, people who do multiple new projects a year, or people who don't care about details, Rome will be great.

For homemade projects, I use CodeKit, and I think Rome will be the same without the friendly and refined GUI.

Re: Rome: A Linter for JavaScript and TypeScript

#113

Earlier quoted context omitted.

I just last week found out about https://rushstack.io/ you might like it.

I 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

totally 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)

Re: Rome: A Linter for JavaScript and TypeScript

#115

I 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.

That was part of the impetus behind ReasonML IIRC, JS tooling in OCaml-ish. Not sure if the performance benefits translated though.

Re: Rome: A Linter for JavaScript and TypeScript

#116
post #108

Earlier quoted context omitted.

I get that - but since TS is also OSS you can fork and upstream, still sounds like less work than writing everything from scratch.

Why? TS and Rome architectural goals are completely incompatible. Writing a transpiler is not complicated at all, especially for someone who has written Babel in the past. On the other hand, if you familiarise yourself with both TS's gigantic codebase and with Rome's goals, you'll quickly see that modifying TS would be much vaster undertaking than writing it from scratch. Also if Rome were just an also-ran to replace…

But you're basically trying to superset the TS compiler. If this doesn't cover TS typechecking then it fails on it's promise of a single pass compiler stack.

Are you suggesting that TS team is so incompetent or legacy burdened that their codebase is impossible to extend. What use case of TS would you exclude to arrive at simpler code base ?

Writing a transpiler that ignores type checks is probably simple but also quite useless for dev workflow - if I need to run a separate type checker might as well run a separate linter and compiler, the tech is established.

Re: Rome: A Linter for JavaScript and TypeScript

#117

I 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.

That was part of the impetus behind ReasonML IIRC, JS tooling in OCaml-ish. Not sure if the performance benefits translated though.

I 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.

Re: Rome: A Linter for JavaScript and TypeScript

#118

Earlier quoted context omitted.

I removed Babel from my toolchains a while ago, so it's even shorter: TS, ESlint, Prettier, Webpack.

Same, but I wouldn't say I'm happy with it. Everything's interdependant and that makes it such a pain to configure and maintain: - Prettier has to be integrated with ESLint to avoid conflicting formatting and for good devX - TS config interferes with ESLint config ("this file is not part of any project" or conflicting unused var warnings) - Webpack has to be integrated with TS to compile down to JS - ESLint, TS and W…

Exactly. Let's say Eslint, TS, Prettier, Jest, and Webpack, are just standard for most projects I start.

The problem is, each little issue a developer has, often requires not just installing these, but then adding a whole bunch of plugins to make them work together. So whenever I start a project, my package.json is just already packed with a gazillion of devDependencies from @types/ to eslint and webpakc plugins.

Re: Rome: A Linter for JavaScript and TypeScript

#119

I 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.

That was part of the impetus behind ReasonML IIRC, JS tooling in OCaml-ish. Not sure if the performance benefits translated though.

They 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.
Post reply on HN