The TypeScript 2.0-typescript branch seems to be lagging and isolated, with all components having 2.0-preview branches yet the 2.0-typescript README has not even been changed from the 2.0-preview text. Until a proper Polymer/TypeScript workflow is recommended and supported by the Polymer team, the basic idea is to maximize on the use of the essential features that TypeScript offers and not invest too much into hard-core features that require the workflow to be tightly coupled with late-bound transpilation of complex TypeScript projects (with modules / loaders). Another thing to address is how Hydrolysis fails to analyze and iron-component-page fails to document TypeScript-based components, not making good use of the elegant property declarations and decorators used in TypeScript. For now, a temporary workaround is needed to ensure that properties are defined and documented with proper types and default values, but the workaround needs to be easily replaceable once we have better Polymer/TypeScript support from the Polymer team.
While we wait for awesome TypeScript libraries and definitions from the team, it is important to figure out the road with least resistance and easier refactoring!
Since the 2.0-typescript branch is not getting priority at the moment, I suggest we use the 2.0-preview branch as much as possible to get the most cross-component compatibility until a more stable 2.0-typescript release.
It is more predictable to use approaches that closely mimic the conventions of working with Polymer/Vanilla until a more stable Polymer/TypeScript ecosystem is in place. So custom elements need to be 100% link/import compatible, transpiled on save and not later in the workflow, which means we must avoid using modules and module loaders (like System.js), and structure the classes properly to be compatible with Hydrolysis Analyzer. To overcome some of the issues that are obviously going to be phased out, custom elements should ideally extend an abstract class which extends from Polymer.Element, this abstract class will be used to resolve any transient issues (hide the ugly workarounds) until things are more stable, then it would be possible to remove the abstract class and extend from Polymer.Element directly.
Until there is a stable Polymer/TypeScript workflow, we need to make TypeScript happy with Polymer. By extracting a copy of the types from the 2.0-typescript branch and keeping them locally scoped it is possible to create transpilable TypeScript implementations today with a greater degree of stability, making the transition to the up-coming Polymer/TypeScript workflow predictably controlled. It is also a good idea to extract the decorators.ts and compile them de-modularized into a decorators.js to be able to use decorators without depending on module loaders until an ideal workflow is identified.
Until Polymer 2.0-preview testing is more stable, let's not touch this topic!
Really appreciate this! Going to use this as a starting point to get mine going.