ember-cli-typescript 2.0

[dfreeman]

Overview

This v2 branch tracks progress toward a 2.0 release of ember-cli-typescript, which will hopefully alleviate a lot of the pain that folks both consuming and developing the addon have felt over the course of 1.x. The aim is to land incremental PRs against this branch and cut periodic beta releases from it to get early feedback and enable folks who want to experiment with things the new build approach will unlock.

The primary planned change with 2.x is a switch from using tsc to using @babel/plugin-transform-typescript for transpiling .ts files. This comes with certain tradeoffs (outlined below) but has the massive benefit of playing more nicely with the rest of the ember-cli ecosystem and eliminating a lot of complex and fragile code that we're currently maintaining.

Breaking Changes

• The addon will need to be a dependency rather than a devDependency for addons. To this end, we've done work during the 1.x era to factor out all the blueprints (which accounted for a large portion of our dependency weight) into a separate addon, which in 2.x will need to be installed in the host alongside ember-cli-typescript itself.
• We'll no longer supply a custom watcher to the TypeScript compiler, so the torrent of fs events coming from tmp may bog typechecking down on some systems. Ember CLI 3.5 moves tmp out of the project directory, eliminating that issue, so we should likely say that 3.5 is our minimum supported CLI version for the 2.0 release.
• Using Babel for transpilation brings a couple of limitations (see the announcement blog post for further details)
  • namespace, const enum, and enums that span multiple declarations are all unsupported because emitting code for them requires type information
  • <type>expr-style casting is unsupported because it conflicts with JSX syntax (but expr as type is preferred anyway)
  • there are currently some known bugs in Babel's TS parsing implementation where it will reject valid TypeScript syntax (e.g. get foo(this: bar)), but these should be resolved over time and we as a community can contribute fixes as necessary
• Published addons will no longer be able to include .ts files in their app directories (this is how ember-cli preprocessors work, and we've been cheating up to now—I regret caving on that 😉)
  • In-repo addons will still be able to use .ts files in their app directories (assuming the root app itself uses ember-cli-typescript); transpilation for addons' app files is managed by the host app's preprocessors
• Apps that are overriding files provided by addons in their app trees must use .js files to do so.
  • This is due to ember-cli-babel being unable to know which file should override the other if they have different extensions.
  • While this is a fairly common pattern for customizing addon behavior, it's not necessarily a good one, and not one MU intends to support

To Do

Items on this list will be checked off as PRs land, and additional entries will also likely be added as they're discovered.

• Use Babel for transpilation rather than tsc
  • Register plugins and extensions in the host's Babel config
  • Emit a warning if Babel 7 isn't present
  • Update ts:precompile command to only emit .d.ts files, since .ts ones will be used as part of the regular Babel build process
• Release ember-cli-typescript-blueprints@2.0-beta.x
  • Emit .js files in the app/ directory for addons, not .ts ones
  • Update in-repo addon blueprints to add ember-cli-babel and ember-cli-typescript as dependencies
• Install ember-cli-typescript-blueprints@2 in the host as part of the default ember-cli-typescript blueprint (remove from our own dependencies)
• Typechecking
  • Emit type errors to the console during build
  • Support failing single builds due to type errors
  • Support failing rebuilds (ideally with nice in-browser feedback) due to type errors
• Prune unused code and dependencies
• Place generated declarations based on paths config rather than hard-coded knowledge of typical project structure
• Warn if we detect ember-cli < 3.5?
• Set isolatedModules by default
• Write a migration guide (this probably needs to be broken out into its own whole set of checkboxes)

[chriskrycho]

Okay, here we go!