[UPDATE] Updates Glimmer-VM and Typescript

[pzuraq]

Updates the Glimmer-VM, and Typescript/ember-cli-typescript. The update
to TS was necessary due to updates from the Glimmer-VM. Updating ec-typescript
to make sure that published types near the same version that it supports also
seems to make sense.

[mike-north]

Following a discussion w/ @pzuraq , here are some of my suggestions to help (partially/marginally) insulate consumers of this library from type-related breakage (mostly due to the large number of breaking changes associated with the 2.9.x -> 3.5.x TS compiler bump)

• Add some positive and negative test cases for the types, using either https://github.com/SamVerschueren/tsd or https://github.com/microsoft/dtslint
  • dtslint will require some special configuration, because by default it always runs tests against typescript@next which can be noticeably unstable at times
  • tsd does not have any built-in functionality for testing a range of compiler versions like dtslint does
• Use api-extractor to detect unintentional exports and changes to the public API surface (i.e., accidental leakage of private types through the public API)
• Create an ember-try-like script that runs the aforementioned test suite with each version of the TS compiler that this library aims to support (keeping in mind that developers who are not writing TS, but author code in a ts-aware editor are often impacted by breakage around type information)
  • I would suggest at least supporting TS 3.3.x because
    • It's the last release before some major performance regressions were introduced in TS 3.4.x.
    • TS >= 3.5 included some breaking changes that were more difficult to adapt to than usual

[pzuraq]

To be clear, prior to this change, types were being compiled with TS 3.2.3, not 2.9.x. This is part of the reason I bumped the version of ec-typescript, the actual compiled types for the built packages are currently supplied by broccoli-typescript-compiler (same across the whole monorepo), and we're just using ec-typescript to strip types with Babel.

Overall though, I agree with the rest of the points, I think it's good idea to add type tests now since they're effectively going to be part of the public API for these packages. Will add them to this PR, before the upgrade commits, so we can ensure no breakage is happening.

[mike-north]

Overall though, I agree with the rest of the points, I think it's good idea to add type tests now since they're effectively going to be part of the public API for these packages. Will add them to this PR, before the upgrade commits, so we can ensure no breakage is happening.

sounds like a good idea. I'd make a quick script to ensure the tests are run w/ TS 3.2.3 so that we know they remain compatible. This is a shell script I use for a travis-ci test matrix to validate against multiple TS versions

[mike-north]

type testing LGTM

[tomdale]

This looks great. I am happy to merge. However, would you mind including a few paragraphs in the README or somewhere else giving a high-level mental model for how to think about these type tests and the workflow associated with them.

For example, from my understanding, adding a new property to the Component class will cause the type test to fail. If I want to add new API, what is my workflow for doing that? How do I run the tests to verify my changes? How and when do we test for internal implementation details, e.g. we're currently testing the existence of two private symbols—how should I as a contributor think about things like that? Links to external resources would be fine as well. Just so we all have a shared mental model.

[tomdale]

What is the rationale for including type tests for these?

[pzuraq]

There's no way to not include them in the type check, unfortunately, it would throw an error since they exist on the object.