Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rome: A Linter for JavaScript and TypeScript

romefrontend.dev

Post reply on HN
Print view View original

121–130 of 140 posts

Re: Rome: A Linter for JavaScript and TypeScript

#121

Post by wildpeaks »

topicseed wrote: post #118
williamdclt wrote: post #103

Earlier quoted context omitted.

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.

This is the reason why I wrapped my Webpack config in its own package (same with Eslint), that way I pretty much only have a single dependency to add when starting or maintaining a project (and if a project has a very unique need, it can still modify the config generated by the package).

The package has a bunch of automated tests, so Dependabot checks for me if dependency updates are still compatible with the way I expect them to behave (and if a dependency needs to be swapped by another, I only need to do it in one place).

Re: Rome: A Linter for JavaScript and TypeScript

#122

Post by bishalb »

esperent wrote: post #68
elondaits wrote: post #33

Earlier quoted context omitted.

Rome is the current capital of Italy... not a mythical or ancient thing.

However, it is a little bit weird to name a programming tool after a country's capital city. Are we gonna get the London linter next? Or the Washington DC web framework?

There is a web framework called Chicago boss already.

Re: Rome: A Linter for JavaScript and TypeScript

#123

Post by brundolf »

rubber_duck wrote: post #116
rmthw wrote: post #108

Earlier quoted context omitted.

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 qui…

The TypeScript plugin for Babel already works this way: it strips out the type annotations to make the code understandable to plain JS interpreters, nothing more. Most people do their type checking through their editor or some other tooling. The coupling of building and checking in a single step, in the case of a dynamic language, is really just a matter of convenience for the implementers (as well as historical tradition). Unlike C, in TypeScript type information is not actually needed to output runnable code.

Re: Rome: A Linter for JavaScript and TypeScript

#124

Post by CURLY3Y »

esperent wrote: post #68
elondaits wrote: post #33

Earlier quoted context omitted.

Rome is the current capital of Italy... not a mythical or ancient thing.

However, it is a little bit weird to name a programming tool after a country's capital city. Are we gonna get the London linter next? Or the Washington DC web framework?

There is also Istanbul a test coverage tool and their CLI named nyc.

Re: Rome: A Linter for JavaScript and TypeScript

#125

Post by schwartzworld »

Aeolun wrote: post #38
topicseed wrote: post #5

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.

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

Parcel is pretty amazing

Re: Rome: A Linter for JavaScript and TypeScript

#126

Post by schwartzworld »

rattray wrote: 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…

it's weird that you think of TS as being a settled-on part of the stack.

Re: Rome: A Linter for JavaScript and TypeScript

#127

Post by rubber_duck »

brundolf wrote: post #123
rubber_duck wrote: post #116

Earlier quoted context omitted.

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 qui…

The TypeScript plugin for Babel already works this way: it strips out the type annotations to make the code understandable to plain JS interpreters, nothing more. Most people do their type checking through their editor or some other tooling. The coupling of building and checking in a single step, in the case of a dynamic language, is really just a matter of convenience for the implementers (as well as historical trad…

I know how it works and I work with TS on a daily basis - the problem is you can't rely on editor type checking because all editors (Idea and TS language server) do type checking on the currently open file - so as soon as your module is referenced from somewhere else you won't get editor notifications if your changes broke that module unless you open that file - using this alone is useless on large projects.

I would argue editors already do a better job at linting and lint rules are mostly file local anyway so the "single pass lint on each build" is not that useful.

Having type checking as a part of the compile process is the best way to leverage typescript (you can fork the checking process so it doesn't block output for faster reload experience)

Re: Rome: A Linter for JavaScript and TypeScript

#128

Post by brundolf »

rubber_duck wrote: post #127
brundolf wrote: post #123

Earlier quoted context omitted.

The TypeScript plugin for Babel already works this way: it strips out the type annotations to make the code understandable to plain JS interpreters, nothing more. Most people do their type checking through their editor or some other tooling. The coupling of building and checking in a single step, in the case of a dynamic language, is really just a matter of convenience for the implementers (as well as historical trad…

I know how it works and I work with TS on a daily basis - the problem is you can't rely on editor type checking because all editors (Idea and TS language server) do type checking on the currently open file - so as soon as your module is referenced from somewhere else you won't get editor notifications if your changes broke that module unless you open that file - using this alone is useless on large projects. I would…

It's entirely possible then to use tsc as a "global" typechecker for the purposes of your dev workflow, without making it a part of your build process (unless you're doing CI, in which case it could still be a separate, preliminary pass that doesn't have to be bound up in the actual build stage). All I'm saying is, especially for a project like Rome that has so many other irons in the fire, I think it's a fully legitimate decision to focus on builds alone and parse-but-not-typecheck TypeScript code, leaving the latter to projects like tsc that have much bigger teams and already do a great job of it.

Re: Rome: A Linter for JavaScript and TypeScript

#129

Post by WorldMaker »

Aeolun wrote: post #38
topicseed wrote: post #5

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.

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

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

Re: Rome: A Linter for JavaScript and TypeScript

#130

Post by rubber_duck »

brundolf wrote: post #128
rubber_duck wrote: post #127

Earlier quoted context omitted.

I know how it works and I work with TS on a daily basis - the problem is you can't rely on editor type checking because all editors (Idea and TS language server) do type checking on the currently open file - so as soon as your module is referenced from somewhere else you won't get editor notifications if your changes broke that module unless you open that file - using this alone is useless on large projects. I would…

It's entirely possible then to use tsc as a "global" typechecker for the purposes of your dev workflow, without making it a part of your build process (unless you're doing CI, in which case it could still be a separate, preliminary pass that doesn't have to be bound up in the actual build stage). All I'm saying is, especially for a project like Rome that has so many other irons in the fire, I think it's a fully legit…

But what's the value proposition of this solution then ? If I need to run separate processes anyway what's the benefit over running webpack with TS and a fork checker ?
Post reply on HN