Merge pull request #808 from emberjs/amend-724

Amend RFC 0724 to include template type checking

Author: chriskrycho

text/0724-road-to-typescript.md

@@ -28,8 +28,6 @@ This RFC declares our intent to officially support TypeScript as a peer to JavaS
   - [Defining Official Support](#defining-official-support)
   - [Constraints](#constraints)
   - [Non-Goals](#non-goals)
-    - [Superseding or replacing JavaScript](#superseding-or-replacing-javascript)
-    - [Typed Templates](#typed-templates)
   - [Roadmap](#roadmap)
     - [RFC Required](#rfc-required)
       - [Types](#types)
@@ -97,6 +95,7 @@ Key implications of this commitment:
 
 - The Semantic Versioning specification, including definitions of SemVer for TypeScript types and TypeScript compiler support policy, will be a key artifact of this process. Without it, we will not be able to provide the stability guarantees Ember users have come to rely on.
 
+- Given the importance of templates in Ember and Glimmer apps, “typed templates” are a key part of the path to adopting TypeScript as a community. TypeScript-powered integration between the template layer and the JavaScript context is a key goal for the Typed Ember team already. It is not a *gating feature* for Ember packages to officially supply TypeScript. Instead: the feature can be rolled out and integrated with Ember CLI, the Ember Language Server, and other tooling whenever it is ready, decoupled from the other efforts here. However, given its importance as one of the primary API boundaries within Ember and Glimmer apps, our definition of official Ember support would be incomplete without it.
 
 ### Constraints
 
@@ -110,23 +109,13 @@ The following are our hard constraints in supporting TypeScript with Ember:
 
 ### Non-Goals
 
-The combination of constraints and ecosystem status lead us to several non-goals for this effort. A *non-goal* here means that it is not part of the initial road to making TypeScript available. 
-
-
-#### Superseding or replacing JavaScript
+The combination of constraints and ecosystem status lead us to a key non-goal for this effort. A *non-goal* here means that it is not part of the initial road to making TypeScript available.
 
 This RFC aims to *add* a new first-class language to the Ember support matrix. However, it does *not* recommend replacing JavaScript with TypeScript. To the contrary: this is an explicit non-goal. Per the constraints described above, adding first-class TypeScript support should be a net positive for JavaScript-only Ember developers.
 
 Additionally, this RFC does not propose changing the *default* experience from JavaScript to TypeScript even once we have full support for TypeScript.
 
 
-#### Typed Templates
-
-This roadmap RFC explicitly does not require support for “typed templates” as part of the path to adopting TypeScript as a community. TypeScript-powered integration between the template layer and the JavaScript context is a key goal for the Typed Ember team already. However, it is not a *gating feature* for Ember to officially support TypeScript. Rather: the feature can be rolled out and integrated with Ember CLI, the Ember Language Server, and other tooling whenever it is ready, decoupled from the other efforts here. If we reach a point where full support for type-aware template integration exists and is sufficiently robust, we can consider adding it to our definition of official Ember support via a dedicated RFC.
-
-The *only* relationship those efforts have to this roadmap is that they will inform the design of the `@glimmer/component@2.x` TypeScript API (as described below under **Roadmap**).
-
-
 ### Roadmap
 
 With this definition and associated design constraints in mind, the path to full TypeScript support in Ember requires RFCs to address key blockers, as well as some implementation details which do not require RFCs but are important for successfully delivering TypeScript support to our users..
@@ -179,6 +168,10 @@ There are also a number of key implementation concerns which must be addressed,
 
 - **How do app and addon authors *consume* published types?** There are a few “gotchas” about how TypeScript supports features like autocomplete in a project, which primarily affect the very first few interactions end users have with TypeScript, which we should address via tooling. How this works is closely related to where the type definition files are generated during publication, and so will likely need to be solved in conjunction with that issue.
 
+- **What should the final design for template-aware type checking be?** [Glint][glint] has a number of decisions which make good sense and indeed are necessary for template-aware type checking given both the design constraints of the Octane era and its own experimental status. However, we should nail these down before it becomes an officially-recommended tool!
+
+[glint]: https://github.com/typed-ember/glint
+
 
 #### Recommendations