From 74a01306931226094b8527c8192637b3f9848238 Mon Sep 17 00:00:00 2001 From: Chris Krycho Date: Wed, 23 Mar 2022 17:48:03 -0600 Subject: [PATCH 1/2] Amend RFC 0724 to include template type checking RFC #724 originally intentionally excluded template type checking via Glint from its designation of "official support" for Ember. However, in the time since the RFC was authored, there have been two significant changes: 1. Glint itself has matured significantly, with no known major issues at this time (though plenty of polish still to be done). 2. The *major* design issues in Ember needed to unblock Glint have been resolved: - resolution of template identifiers (components, helpers, and modifiers): RFC #779 - a Glimmer Component type signature which exposes information about the blocks and the target for `...attributes`: RFC #748 Although there remain a number of smaller design questions to resolve, this is sufficient for us to treat type-checked templates as a viable part of our story, and given *viability*, we think this is *necessary*. --- text/0724-road-to-typescript.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/text/0724-road-to-typescript.md b/text/0724-road-to-typescript.md index 25d1b321cb..d0bd338284 100644 --- a/text/0724-road-to-typescript.md +++ b/text/0724-road-to-typescript.md @@ -122,9 +122,7 @@ Additionally, this RFC does not propose changing the *default* experience from J #### 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**). +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. ### Roadmap @@ -179,6 +177,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 From 2fbb1ab6d5c93d60819b074ffbf9684db79b7e71 Mon Sep 17 00:00:00 2001 From: Chris Krycho Date: Fri, 15 Apr 2022 09:28:24 -0600 Subject: [PATCH 2/2] Move Glint discussion to 'Defining Official Support' The previous addition of the paragraph still had it in Non-Goals, which is literally the opposite of the point of this amendment RFC. Whoops! --- text/0724-road-to-typescript.md | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/text/0724-road-to-typescript.md b/text/0724-road-to-typescript.md index d0bd338284..43eaaaca9a 100644 --- a/text/0724-road-to-typescript.md +++ b/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,21 +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 - -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. - - ### 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..