6 ms·

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 start

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

seanmcdirmid 10y ago
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.
RyanCavanaugh 10y ago
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.
TAForObvReasons 10y ago
With flow you can do one better: type comments! https://flowtype.org/blog/2015/02/20/Flow-Comments.html 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 :)
- Noseshine 10y ago
  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.
- thejameskyle 10y ago
  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.
  - Noseshine 10y ago
    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.
whatever_dude 10y ago
> 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.
- mohamedhegazy 10y ago
  You can just use `--target ESNext` and this will disable all ES features transformations and just erase types.
  - Noseshine 10y ago
    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/7b9a42f9958b072f057d42d506b7e082ebf19974 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.
    - whatever_dude 10y ago
      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.

seanmcdirmid 10y ago

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.

RyanCavanaugh 10y ago

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.

TAForObvReasons 10y ago

With flow you can do one better: type comments! https://flowtype.org/blog/2015/02/20/Flow-Comments.html 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 :)

Noseshine 10y ago
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.
thejameskyle 10y ago
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.
- Noseshine 10y ago
  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.

whatever_dude 10y ago

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

mohamedhegazy 10y ago
You can just use `--target ESNext` and this will disable all ES features transformations and just erase types.
- Noseshine 10y ago
  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/7b9a42f9958b072f057d42d506b7e082ebf19974 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.
  - whatever_dude 10y ago
    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.