Hacker News Reader

Comment by esamatti | Hacker News Reader

Faster and simpler builds setups. And you don't really lose it as your editor will report the type errors. Flow is used like this all the time.

Tried this on a project of mine. Enums seem to work fine for me.

EDIT: There are some issues with enums indeed https://github.com/babel/babel/tree/master/packages/babel-pl...

View on HN

Wouldn't the simpler build setup be to use TypeScript only for compilation? Why would you want to use Babel as well?

>Why would you want to use Babel as well?

Because he thinks you can't do JS development without Babel.

From what I understand, TypeScript doesn't do any transpiling, so if you want to use ES6/2017 features, you're going to need Babel.

(I haven't used TypeScript yet, so I might be wrong)

It does transpiling. You can set the compiler target to es3/es5/es6 in your tsconfig.json and then you don't need Babel.

Typescript has always transpiled to ES5 (by default it transpiles to ES3 actually). See: https://stackoverflow.com/questions/41173215/does-typescript...

The only counter-example that I know of is that async/await were initially only supported when transpiling to ES6, but this is not true since at least 2.2 (https://github.com/Microsoft/TypeScript/issues/5210).

Babel makes it possible to do compilation that TS doesn't do. E.g., you can use esnext language features that TS doesn't support, like do expressions. You can also use babel plugins that add utility, like the Babel power-assert plugin.

One of the common pattern I use when developing with TS is: Change a type definition, look for red squiggles in the current file and fix them then save and build.

The error log shows me the rest of the files that need fixing.

How would you get that with Babel?

I think this is just an editor concern. It could show a list of files with type errors.

But you could just run "tsc --noEmit --watch" which will just report the project wide type errors to the console as you edit files.

Yeah, it doesn't doesn't anything that is multi-file like const enums since Babel operates per file.

(I work on Babel)

This seems like a recipe for disaster after a bad merge. If you have a team of more than one, this sounds like a silly thing to do.

It's fairly common practice with Flow to run type-checks as a part of the build or test step in a standard build/test/deploy workflow in CI, which largely removes the possibility of bad merges arising from type errors. With TypeScript, using the TypeScript compiler, type-checking would simply happen in lockstep with your build step, whereas with the new Babel preset and a separate type-check process, you still have the option of running them in lockstep as 2 separate commands, but you also have the option of running them as separate jobs in parallel, likely leading to significantly shorter build times. It's definitely going to be a huge net improvement to my own workflow, but you're certainly free to stay with the status quo if you feel it suits you better.

Reply on news.ycombinator.com