Hacker News Reader

Comment by Noseshine | Hacker News Reader

Question:

Is it possible to have a setup with TypeScript where it is guaranteed that no code changes occur other than removal of the type information?

I started using Flow, found what it can and can't do and would like to try TypeScript. But only if I can have "types-only", I don't want my code "translated" in any way. I'm writing for the latest node.js version and not for x different browsers, I want to use exactly what that version supports and have no code-changing steps.

With Flow I use flow-remove-types (https://github.com/leebyron/flow-remove-types) to remove the types. It leaves spaces where there was type-related code and doesn't touch the code itself.

View on HN

With flow you can do one better: type comments! https://flowtype.org/blog/2015/02/20/Flow-Comments.html

You actually wrap the type annotations in comments and flow will recognize them. You can use the source with the type comments in your browser!

As an example, the flow checker will read the annotations from `function f(n/:number/, s/:string/) { ... }` but since they are commented in the source code your JS engine ignores them.

This is amazing for typing existing code, since at every step you are merely inserting comments into your code. And your existing minification step will strip them out :)

I figured if I start using Flow I may as well go all the way. My previous setup was to have JSDoc and Closure compiler style (inline) type annotations everywhere. The IDE - WebStorm - picked up on that. I filed tons of tickets with Jetbrains and got more and more issues resolved over time, but with the latest Webstorm there were some regressions and it seemed like they had difficulties with all of this. For example, I kept getting suggestions for properties picked up in clearly impossible places, autocompletion for the JSDoc types stopped working lately, etc.

So I had enough and started with Flow on one file, then two - then I spent a week converting everything to Flow. I actually found a few subtle bugs in my code, but also two or three minor ones in Flow (issues submitted). I also found clear limits for this type system, for example, when you clearly know 100% sure that a value cannot be undefined but Flow insists you add a type check before using the property because it does not follow your dynamic logic, only its types.

Comments is definitely the easiest way to get doing. But also if you're already using Babel and ESLint, you can add Flow in very few steps:

1. Setting up with Babel: (note that if you are already using the "react" preset you don't have to do anything)

    $ npm install --save-dev babel-plugin-transform-flow-strip-types

Then update your `.babelrc`:

    { plugins: ["transform-flow-strip-types"] }

2. Setting up with ESLint

    $ npm install --save-dev eslint-plugin-flowtype-errors

Then update your `.eslintrc`:

    { plugins: ["flowtype-errors"] }

Then just install `flow-bin` and create an empty `.flowconfig` file in the root of your repo and you're done. Now you have Babel compiling your code the same as always and you can use the Flow type syntax, and with ESLint you probably already have your editor all setup to show you warnings.

We're trying to integrate more with tools like this so you don't have to go changing your entire workflow. It shouldn't be so hard to add types to your existing JavaScript code.

For eslint I'm using plugin "flowtype", and under "extends" I have "plugin:flowtype/recommended". Do you happen to know what's different compared to the eslint-flow package you mention? I took the first one I could find, didn't want to spend hours with the eslint part of using Flow since I was busy with all the errors reported by Flow during the conversion process.

EDIT:

Ah I think I get it, it's for editors that don't interface with Flow but only with eslint. Well, since WebStorm has Flow support - even though it's new and there are a few tickets open - I guess I should stick with the plugin that I already chose.

TypeScript and Flow have the same behavior with regard to removing types, and TypeScript and Babel have the same behavior with regard to downleveling ES6+ code to ES5-

If you target ES6 with TypeScript and only write ES6-compliant code (plus types), you won't get any downleveling of features, so your code will always be the same as you wrote it (other than the removal of types).

If you use TS-specific features like 'enum' or 'namespace', there will necessarily be some rewriting of your code to turn it into usable JS, but those features are entirely optional.

TypeScript seems to have been very religious about following "Bracha's law" (types shouldn't effect program semantics), and I'm unaware of any translations they do beyond supporting some new features on previous platforms (e.g. classes on pre-es6).

It is kind of annoying sometimes actually, in that typescript can't support niceties like operator overloading or extension methods because that would require de-sugaring.

> Is it possible to have a setup with TypeScript where it is guaranteed that no code changes occur other than removal of the type information?

Yes and no.

Typescript does a little bit of filling in the gaps of some missing features if the target platform does not support a feature you used. So your compiled code will still be ES6 (or ES5), but it may have some boilerplate added to polyfill for something if ES6 or ES5 (or others..) do not officially support it.

You can just use `--target ESNext` and this will disable all ES features transformations and just erase types.

Thank you!!! This is the one answer I was looking for. And it seems to be very recent, committed Nov 7 for 2.1:

https://github.com/Microsoft/TypeScript/pull/12160/commits/7...

Looking at the discussion on GitHub for the issue that lead to this commit I'm a little amazed at how much difficulty some people seem to have had with the simple concept. "Just pass it through without code changes, only remove type information." Why does that lead to such convoluted discussions? Oh well, it's been done.

I assume it's because "no code changes" implies you could potentially be creating something that doesn't run where you want it to. Modern JS development means you need to be aware of the EcmaScript version you're writing in, and the version you're targetting. Once you're aware of it, transpiling with TypeScript means you don't necessarily need to target `esnext`: if you write ES5 and target ES5, it'll just remove the types as expected.

The downside of using `esnext` everywhere is that someone might be employing a feature that is not widely supported in the target browser/JS engine. So it's pretty bad to start with that as a default without an understanding of the consequences.

  "no code changes" implies you could potentially be creating 
  something that doesn't run where you want it to.

Eh... I don't see how those arguments are possibly serious? Is this forced hand-holding of adult people truly your attitude? I deliberately select a non-default option. You (not directly you probably, but you chose to represent that POV) don't know anything about me or my situation. But immediately you start worrying about stuff you don't know anything about, that I might not know what I'm doing, might... could... possibly... hypothetically... Sorry, but this reply, or the attitude you presented which I know may not be your own, really pisses me off, to say it quite frankly. Don't even try to defend the forced(!) nanny attitude, even if you just tried to present what you think is other people's argument.

"You" in my comment means a hypothetical person who could be doing the changes. It wasn't directed at you personally, since it's obvious I know nothing about your context or environment.

I'll be more careful about writing "one" instead of "you" next time.

Reply on news.ycombinator.com