It does. And it's a risk not keeping up with their pace of development. Supporting those "compilers" is just supporting their syntax, which both fortunately already have very good compliance test suites because other tools like Babel already reimplement their syntax anyway.

Interesting. Do you mean that Rome won’t perform type-checking in TypeScript/Flow, it just strips their type annotations (like their respective Babel plugins do today)? If so, is the idea that people might continue to use the tsc/flow binaries in parallel with Rome (e.g. if they want to validate types in a commit hook, or for in-editor linter-style warnings)?

I've been really looking forward to this source release since reading your tweets about it. Sorry it got posted to HN before you wanted it to, but thanks for making the code public at this stage.

> is the idea that people might continue to use the tsc/flow binaries in parallel with Rome

I think so, in the same way that people use both Babel and TypeScript (or Flow) today. TypeScript/Flow check the types, while Babel simply strips them out when compiling the code.

Well, Typescript is literally checked in to the repo under node_modules. So I imagine the author just means "forget lockfiles, let's check this all in."

The TypeScript type checker is only used to type check the Rome source code. The compiler is not used at all.

Do you plan to self-host at some point, and get rid of the dependency on the (external) TS compiler?

As I understand it, the goal is not for Rome to do type-checking, but just for it not to choke on TypeScript's syntax (i.e. what Babel does):

> Supporting those "compilers" is just supporting their syntax, which both fortunately already have very good compliance test suites because other tools like Babel already reimplement their syntax anyway.

Yeah I'm really not impressed at how e.g. Typescript support is often through Babel instead of the official TSC compiler.