TypeScript 2.3

The "feature" I'd like to see most is a "perfect setup" guide (or maybe auto-detecting-and-helping logic?) detailing what's required to get all the features working. Currently for example I don't get HTML/CSS formatting, even though it was featured in 0.6.0 changelog, but I have no idea why :-/ . Got this feeling a few times with vetur as well as other linters: things work, but maybe not 100%, and it can be opaque to dig deeper: is it due to vscode misconfiguration? vetur misconfiguration? missing tooling? I don't know.

EDIT: these TS-dependent auto-completions look fantastic. I'm planning to migrate my current Vue project to TS, but for now it's just JS. Do you have any recommendation for Vue2-with-TypeScript documentation? Or, even better, a JS-to-TS Vue2 migration guide?

I worked on this for electron-compile but unfortunately React HMR itself (react-proxy) fails with actual classes (i.e. using the `class` keyword not-transpiled) or anything other than Babel's ES5 class keyword transpiler. Once they fix that, apps created via electron-forge or that use electron-compile will get TypeScript HMR automatically.

TypeLite (https://www.nuget.org/packages/TypeLite) can get you halfway there with C#. I used that for a while before eventually wanting more and rolling my own solution, which takes a WebAPI endpoint and generates typed fetch methods. It's not anywhere close to polished or reusable, unfortunately.

I haven't touched TS since ~1.3, but this was all working well back then at least.

http://docs.servicestack.net/typescript-add-servicestack-ref...

Disclaimer I work for ServiceStack

1. Number of existing type definitions in DefTyped vs. FlowTyped and packages that provide typings. TypeScript has way more type definitions

2. Tooling, TypeScript has a much better tooling support

3. Project popularity: number of downloads, GitHub issues and pull requests etc. TypeScript is much more popular.

Syntax and personal opinions was not part of our decision making process.

https://github.com/styfle/react-server-example-tsx/blob/mast...

TypeScript:

- Structurally typed

- Enum types

- Mapped types

- Abstract classes

- Scoped class members (public, private, protected)

- Namespaces

Flow:

- Nominally typed

- Covariance/contravariance annotations

- Supertype annotations (via $Supertype type)

- Subtype annotations (via $Subtype type)

- Arity annotations (via $Pred type)

- Subtraction types (via $Diff type)

- Opt-in 2-way type resolver (via * type)

- Refer to nested type (via $PropertyType type)

Otherwise, the two are remarkably similar.

I've been using TS for a few years, and Flow for a few months. Please correct me if any of the above are wrong.

The main takeaway for me is that TS is much much less sound than Flow. That means it checks less invariants which in turn makes you less trust it...

Consider the following code which is valid (!) in TS:

    let promisedString: Promise<string> = new Promise(
      resolve => {
        // Perfectly valid in TypeScript!
        resolve(42)
      }
    )

Even the following simple piece of code will make TS ask you to annotate doAddition function:

    export function addition(a: number, b: number) {
      return doAddition(a, b)
    }

    function doAddition(a, b) {
      return a + b
    }

Edit: spelling

For switching a large existing JS codebase, it's easy to add flow comments without changing the final minified builds, allowing you to reap the full benefits of the type check.

If there's something you really need in Babel, you can always transpile to ES6, then put it through Babel.

It did need some tweaking to the tsconfig.json file, but that's a one time setup.

In my experience, in some organisations, it's hard to introduce TypeScript instead of JavaScript, because of reasons. For example, one of my clients made a bet on CoffeeScript back in the days, and that didn't work out, so now they are hesitant to adopt anything. Being able to introduce at least the type checking feature will start to drive change to this hesitation.

Please let us know if you see any errors while trying out new TypeScript 2.3 features in VSCode or have any thoughts on how our JS/TS support could be improved: https://github.com/Microsoft/vscode/issues/new

interface Test{

number? myOptionalNumber;

}

Is that what you mean?

[0]: https://blog.mariusschulz.com/2016/09/27/typescript-2-0-non-...

    /** Represents optional values, just as F# does. */
    export type Option<T> = T | null | undefined;

    /** Option operators. */
    export namespace Option {
        /** Constructs a Some(value) option. */
        export function some<T>(value: T): Option<T> {
            return value;
        }

        /** Returns true if the value is Some value and false otherwise. */
        export function isSome<T>(value: Option<T>): value is T {
            return value !== undefined && value !== null;
        }

        /** Constructs a None option. */
        export function none<T>(): Option<T> {
            return null;
        }

        /** Returns true if the value is null or undefined and false otherwise. */
        export function isNone<T>(value: Option<T>): value is null | undefined {
            return value === undefined || value === null;
        }

        /** Recovers an Option<T> from JSON object representation. */
        export function fromJSON<T>(json: any): Option<T> {
            return isSome(json) ? <T>(json[0]) : null;
        }

        /** Converts to a JSON representation. */
        export function toJSON<T>(value: Option<T>): any {
            return isSome(value) ? [value] : null;
        }

        /** Unpacks with a default value. */
        export function withDefault<T>(value: Option<T>, defaultValue: T): T {
            return isSome(value) ? value : defaultValue;
        }
    }

Again, we've seen this in languages with macros. At least with macros it's part of main codebase; you usually have to include them in some way. With these AST transform systems the secret is tucked away in a build script somewhere.

One aspect that's disappointing to me is that the AST they use seems fairly idiosyncratic; Babel's is quite close to the ESTree spec, and even easier to work with.

Relatedly, it also doesn't look possible to swap out the parser, which Babel makes easy. I'd love to use the TS typechecker for a compile-to-js lang I'm working on ([0]), but would need to use my own parser.

[0] http://lightscript.org

Async iterators are very exciting and builds should be faster without babel in the pipeline.

Main purpose is to make JavaScript code easier to maintain, especially across teams.

IMO the only way to go "higher level" is to use something like jQuery.

Angular is another story.