Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Official TypeScript support #724

Merged
merged 5 commits into from Mar 4, 2022
Merged

Conversation

chriskrycho
Copy link
Contributor

@chriskrycho chriskrycho commented Mar 11, 2021

TypeScript has become a key part of the front-end development ecosystem over the past several years, and powers many of the best developer experiences in the broader JavaScript ecosystem. Ember was a relatively early TypeScript adopter for its internals, and there is widespread usage in the ecosystem with community support from the Typed Ember team, but to date Ember has not provided “out of the box” or official support for authoring apps or addons in TypeScript.

This RFC declares our intent to officially support TypeScript as a peer to JavaScript, in a way which makes the developer experience better for all Ember developers. It outlines the key constraints and goals for the effort, details a roadmap for accomplishing those goals, and provides the following definition of official support (from the Detailed Design: Defining Official Support section in the RFC text):

Ember officially supporting TypeScript means: All libraries which are installed as part of the default blueprint must ship accurate and up-to-date type definitions for the current edition. These types will uphold a Semantic Versioning commitment which includes a definition of SemVer for TypeScript types as well as a specification of supported compiler versions and settings, so that TypeScript will receive the same stability commitments as the rest of Ember.

Rendered Text


Note: this RFC is focused on the question of whether we should adopt TypeScript, and if so how. It is not, however, the right RFC for discussing the specific concerns it identifies. Discussion should focus on:

  • whether Ember should or should not aim to support TypeScript as a first-class citizen
  • if it should adopt TypeScript, whether there are any gaps in the proposed roadmap

TypeScript has become a key part of the front-end development ecosystem
over the past several years, and powers many of the best developer
experiences in the front-end ecosystem. Ember was a relatively early
TypeScript adopter for its internals, and there is widespread usage in
the ecosystem with community support, but to date Ember has not provided
“out of the box” or official support for authoring apps or addons in
TypeScript.

This RFC declares our intent to make TypeScript a first-class citizen of
the Ember ecosystem, as a peer to JavaScript, in a way which makes the
developer experience better for *all* Ember developers. It outlines the
key constraints and goals for the effort, details a roadmap for
accomplishing those goals, and provides the following definition of
official support (from the Detailed Design: Defining Official Support
section in the RFC text):

> Ember officially supporting TypeScript means: _**All libraries which
> are installed as part of the default blueprint must ship accurate and
> up-to-date type definitions for the current edition. These types will
> uphold a Semantic Versioning commitment which includes a definition of
> SemVer for TypeScript types as well as a specification of supported
> compiler versions and settings, so that TypeScript will receive the
> same stability commitments as the rest of Ember.**_
@rwjblue
Copy link
Member

rwjblue commented Mar 11, 2021

@chriskrycho - Thanks for working on this! I'm definitely excited to move forward here!

@rwjblue rwjblue added T-infrastructure T-Tooling RFCs that impact tooling, like Ember Inspector labels Mar 11, 2021
@scalvert
Copy link
Contributor

scalvert commented Mar 12, 2021

@chriskrycho I'm a huge +1 on this RFC, generally speaking. It's been a challenge authoring Ember addons using third-party types à la DefinitelyTyped. While I'm thankful that those that contributed to DefinitelyTyped did, it's a challenge using types derived through third-party interpretation vs. first-party types.

Thanks for doing this!

@srsgores
Copy link

Based on what I read, it sounds like this will more or less allow developers to use TypeScript out of the box without having to install ember-cli-typescript. If that's the case (in which we just update documentation and provide TypeScript examples in addition to regular JS examples), I don't have too much of a problem.

However, if we intend to move TypeScript as a "first-class citizen", then I think we should consider the cons listed in this RFC:

  • Increased cognitive load and learning required. As a newcomer, one might easily become dissuaded by the complication introduced by yet another language?
  • Reliance on another third-party tool which could become obsolete; whereas we can assert the lifespan of JS, to some level of certainty, based on the standards provided by the ECMAScript committe.

If ember decided to adopt TypeScript as a "first-class citizen", that would endanger the library from falling into the same pitfall Angular 2 (and over) did. A lot of developers got scared away and abandoned the framework due to the radical changes imposed.

That doesn't mean that Ember can't do it, but I think we should tread carefully in this endevour.

Angular 2 introduced what, in the Ember world, we know as Ember Engines (Angular Modules). With the adoption of TypeScript came the concept of interfaces, documentation in TypeScript, and decorators such as @Injectable. Ember already has decorators like this: @service, @computed to name a few of the most common. Do you think it helps that new developers have to learn that interface only applies to a specific, compiled language that the browser can't understand?

Definitely Typed

TypeScript presents the main benefit of allowing developers to see method parameters and requirements in real-time via VS Code. While this does provide a benefit to the writier, we can also get the same affordance with older tools like jsdoc. Note that the repository currently doesn't follow the spec and can easily add support for method and type definitions supported in JSDoc with minimal effort (simply editing the comments before each method definition.

Therefore, I think it makes more sense to just use JSDoc before jumping for more tooling and imposing a learning requirement on developers.

A quick Google search reveals that TypeScript has more problems than we may have thought. Of course, we can easily find reasons to or not to use a certain technology, but I argue that with the trend of tooling becoming less favourable, it makes more sense to opt for less tooling over more.

@chriskrycho
Copy link
Contributor Author

chriskrycho commented Mar 14, 2021

@srsgores thanks for your comment. I think it’s a great chance to be extra clear about what this RFC does and does not propose.

If ember decided to adopt TypeScript as a "first-class citizen", that would endanger the library from falling into the same pitfall Angular 2 (and over) did. A lot of developers got scared away and abandoned the framework due to the radical changes imposed.

If we were following the path Angular took, where TypeScript became the only supported language and JavaScript was demoted to a second-class language (at best), I would share your hesitation on this point. But we are not following that path! Our goal is to make TypeScript as equally-well-supported as JavaScript, not to push JavaScript aside. As such, the RFC expressly outlines a number of key differences between what we're proposing and what Angular did. As described under Constraints:

  • We must not compromise our commitment to “stability without stagnation” and our strong Semantic Versioning guarantees.
  • Using TypeScript should never be mandatory for anyone who uses Ember.
  • TypeScript support must never degrade the experience of JavaScript users, and wherever possible it should benefit both JavaScript and TypeScript developers.

And, from Non-Goals: Superseding or replacing JavaScript:

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.

These constraints represent critical differences from the path Angular took. (They are in fact directly informed by watching Angular's problems!) Angular violated all of those principles. We take them as hard and fast guidelines on our adoption.

TypeScript presents the main benefit of allowing developers to see method parameters and requirements in real-time via VS Code.

This is a mostly-accurate summary of the direct benefits for JavaScript-only developers. However, for authors working in TypeScript, the feedback provided by supplying up-to-date, accurate, and well-tested types is much stronger: it can actually prevent whole classes of bugs.

Moreover, while JSDoc annotations can provide a similar degree of benefit purely on the autocomplete and documentation side if the JSDoc annotations are published in modules, that approach would have a number of significant downsides vs. publishing TypeScript types:

  • It would require making substantial changes to the framework’s development workflow tooling to make sure those modules were present in a way visible to end-users.
  • There is no way to actually test those comments for correctness and stability over time. There are ways to provide tests for type definitions (we’re already doing it in a number of non-core packages).
  • There is no way to guarantee that the types as specified in the docs are accurate over time.
  • The experience of authoring types via JSDoc annotations which refer to types in other files, and which can be resolved by modern editor tooling, is very bad. So much so that it's effectively a non-starter.
  • It also duplicates effort within the source code, which is authored in TypeScript already. That's true of type definition files as well… but once the source can become the canonical source of the types, that duplication simply goes away. With JSDoc, that duplication of effort would stick around forever.

Additionally, it’s worth noting that in most modern editors, the JSDoc-powered feedback is actually still TypeScript-powered feedback! It’s just a weaker and worse version of what can be provided by type definitions.

I think it makes more sense to just use JSDoc before jumping for more tooling and imposing a learning requirement on developers.

If you mean “imposing a learning requirement on developers of Ember itself” that learning requirement already exists: much of Ember is written in TypeScript already. If you mean “imposing a learning requirement on developers of Ember apps and addons,” then nothing about this proposal would do any such thing. It would particularly benefit TypeScript developers, but it would not impose anything on JS-only developers; indeed, it would only make things better for them (with no effort on their part!). Again: this is an explicit constraint of the effort, and we won't compromise on that commitment!

To address your other points:

  • Increased cognitive load and learning required. As a newcomer, one might easily become dissuaded by the complication introduced by yet another language?

This is indeed a concern that we’ll need to think about carefully in how we approach the documentation design! We do not want to overwhelm people as they are just getting started. Particularly for the design of the Guides, we’ll need to figure out the best way to structure them. On the other hand, TypeScript may actually help with API docs, even for JavaScript-only consumers.

  • Reliance on another third-party tool which could become obsolete; whereas we can assert the lifespan of JS, to some level of certainty, based on the standards provided by the ECMAScript committe.

While this is true in a strict sense, there are a few reasons I don’t think it’s relevant to our decision of whether to support TypeScript officially as a framework:

  1. Ember already relies heavily on TypeScript internally, as do many apps and addons. Providing official support does not change that in any way; it just makes the experience better for those users… and for JS-only developers as well!
  2. There is no reason to believe that the language, which is now about a decade old and both one of the fastest-growing and most popular languages in history, will decline any time soon.
  3. There is a straightforward escape hatch if we ever need to remove TypeScript, because TypeScript types can be stripped out and replaced with effectively-identical but types-less JavaScript by TypeScript itself, Babel, and many other tools.
  4. At worst if Microsoft suddenly dropped support for TypeScript we would end up supporting it to the end of an Ember major version, and could drop support for it at that time.

A quick Google search reveals that TypeScript has more problems than we may have thought. Of course, we can easily find reasons to or not to use a certain technology, but I argue that with the trend of tooling becoming less favourable, it makes more sense to opt for less tooling over more.

A quick Google search will also reveal that some people don’t even like delicious chocolate ice cream. 😱 🍨

There is, as far as I can tell, no trend of “tooling becoming less favourable” as far as TypeScript goes. I have looked! The reality is actually very much the opposite: developer surveys consistently show that TypeScript is one of the rare tools that has consistently grown in both usage and developer satisfaction over time—unlike every other tool or framework in the front-end space! Given the surging popularity of the tool, it is fully to be expected that more posts expressing dislike for it will pop up here and there. If 99% of TypeScript users love it and 1% hate it, then when the language grows from having 10,000 users to 100,000 users you can expect the number of haters to grow from 100 to 1,000 as well.

I hope that helps clarify the intent of the RFC and assuage some of your concerns!

@pzuraq
Copy link
Contributor

pzuraq commented Mar 14, 2021

Ember already relies heavily on TypeScript internally, as do many apps and addons.

As an aside, it's really hard to understate just how important and invaluable TS is for Ember's own development process. I learned most of Ember core and Glimmer VM in the past 3 years, when large chunks of Ember (and all of Glimmer VM) had already been converted to TS. I honestly think it would have taken me the better part of a decade to get where I am today without types, and we would likely have had common and consistent regressions that could have been (and in practice, have been) prevented.

Types are, IMO, absolutely crucial to maintaining a large codebase like Ember or Glimmer, and I think providing support for it will help large and small apps that adopt it enormously.

All that said, I completely agree with the sentiments of the past few comments. JavaScript must still be supported as a first class citizen, and the learning path should not require any TypeScript. Support should not mean we regress in our current development experience.

@srsgores
Copy link

@srsgores thanks for your comment. I think it’s a great chance to be extra clear about what this RFC does and does not propose.

If ember decided to adopt TypeScript as a "first-class citizen", that would endanger the library from falling into the same pitfall Angular 2 (and over) did. A lot of developers got scared away and abandoned the framework due to the radical changes imposed.

If we were following the path Angular took, where TypeScript became the only supported language and JavaScript was demoted to a second-class language (at best), I would share your hesitation on this point. But we are not following that path! Our goal is to make TypeScript as equally-well-supported as JavaScript, not to push JavaScript aside. As such, the RFC expressly outlines a number of key differences between what we're proposing and what Angular did. As described under Constraints:

  • We must not compromise our commitment to “stability without stagnation” and our strong Semantic Versioning guarantees.
  • Using TypeScript should never be mandatory for anyone who uses Ember.
  • TypeScript support must never degrade the experience of JavaScript users, and wherever possible it should benefit both JavaScript and TypeScript developers.

And, from Non-Goals: Superseding or replacing JavaScript:

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.

These constraints represent critical differences from the path Angular took. (They are in fact directly informed by watching Angular's problems!) Angular violated all of those principles. We take them as hard and fast guidelines on our adoption.

TypeScript presents the main benefit of allowing developers to see method parameters and requirements in real-time via VS Code.

This is a mostly-accurate summary of the direct benefits for JavaScript-only developers. However, for authors working in TypeScript, the feedback provided by supplying up-to-date, accurate, and well-tested types is much stronger: it can actually prevent whole classes of bugs.

Moreover, while JSDoc annotations can provide a similar degree of benefit purely on the autocomplete and documentation side if the JSDoc annotations are published in modules, that approach would have a number of significant downsides vs. publishing TypeScript types:

  • It would require making substantial changes to the framework’s development workflow tooling to make sure those modules were present in a way visible to end-users.
  • There is no way to actually test those comments for correctness and stability over time. There are ways to provide tests for type definitions (we’re already doing it in a number of non-core packages).
  • There is no way to guarantee that the types as specified in the docs are accurate over time.
  • The experience of authoring types via JSDoc annotations which refer to types in other files, and which can be resolved by modern editor tooling, is very bad. So much so that it's effectively a non-starter.
  • It also duplicates effort within the source code, which is authored in TypeScript already. That's true of type definition files as well… but once the source can become the canonical source of the types, that duplication simply goes away. With JSDoc, that duplication of effort would stick around forever.

Additionally, it’s worth noting that in most modern editors, the JSDoc-powered feedback is actually still TypeScript-powered feedback! It’s just a weaker and worse version of what can be provided by type definitions.

I think it makes more sense to just use JSDoc before jumping for more tooling and imposing a learning requirement on developers.

If you mean “imposing a learning requirement on developers of Ember itself” that learning requirement already exists: much of Ember is written in TypeScript already. If you mean “imposing a learning requirement on developers of Ember apps and addons,” then nothing about this proposal would do any such thing. It would particularly benefit TypeScript developers, but it would not impose anything on JS-only developers; indeed, it would only make things better for them (with no effort on their part!). Again: this is an explicit constraint of the effort, and we won't compromise on that commitment!

To address your other points:

  • Increased cognitive load and learning required. As a newcomer, one might easily become dissuaded by the complication introduced by yet another language?

This is indeed a concern that we’ll need to think about carefully in how we approach the documentation design! We do not want to overwhelm people as they are just getting started. Particularly for the design of the Guides, we’ll need to figure out the best way to structure them. On the other hand, TypeScript may actually help with API docs, even for JavaScript-only consumers.

  • Reliance on another third-party tool which could become obsolete; whereas we can assert the lifespan of JS, to some level of certainty, based on the standards provided by the ECMAScript committe.

While this is true in a strict sense, there are a few reasons I don’t think it’s relevant to our decision of whether to support TypeScript officially as a framework:

  1. Ember already relies heavily on TypeScript internally, as do many apps and addons. Providing official support does not change that in any way; it just makes the experience better for those users… and for JS-only developers as well!
  2. There is no reason to believe that the language, which is now about a decade old and both one of the fastest-growing and most popular languages in history, will decline any time soon.
  3. There is a straightforward escape hatch if we ever need to remove TypeScript, because TypeScript types can be stripped out and replaced with effectively-identical but types-less JavaScript by TypeScript itself, Babel, and many other tools.
  4. At worst if Microsoft suddenly dropped support for TypeScript we would end up supporting it to the end of an Ember major version, and could drop support for it at that time.

A quick Google search reveals that TypeScript has more problems than we may have thought. Of course, we can easily find reasons to or not to use a certain technology, but I argue that with the trend of tooling becoming less favourable, it makes more sense to opt for less tooling over more.

A quick Google search will also reveal that some people don’t even like delicious chocolate ice cream. 😱 🍨

There is, as far as I can tell, no trend of “tooling becoming less favourable” as far as TypeScript goes. I have looked! The reality is actually very much the opposite: developer surveys consistently show that TypeScript is one of the rare tools that has consistently grown in both usage and developer satisfaction over time—unlike every other tool or framework in the front-end space! Given the surging popularity of the tool, it is fully to be expected that more posts expressing dislike for it will pop up here and there. If 99% of TypeScript users love it and 1% hate it, then when the language grows from having 10,000 users to 100,000 users you can expect the number of haters to grow from 100 to 1,000 as well.

I hope that helps clarify the intent of the RFC and assuage some of your concerns!

There's a lot here to take apart, so I'll try to break down my concerns to address each of these points.

Ember interally already relies on TypeScript

This sounds more or less to me like backwards rationalizing. It happens all too much in the field where a company adopts a technology like a SPA "framework", say ReactJS, then reasons that they've already committed to Facebook, so might as well start using the Flux architecture and lock in to Create React App's CLI react-scripts. Then two weeks down the line, the same developers realize they need state management, so they pull in GraphQL. Then the company has to teach all their new developers about the intracacies of GraphQL, resolve functions and so on and so forth. Then the hole only gets deeper and deeper...

Ember aims to solve this by providing a "one-stop-shop" approach where you kind of just "get everything out of the box". No need to think about routing (already there in the built-in router); no need to think about state management (ember data does that). Templates have their own separate files, keeping the logic separated from the markup.

However, adding TypeScript muddies these waters; it won't be long before we sign off on getting rid of .hbs files entirely to "just put everything in one giant file". Developers will ask for type definitions on helpers, and then what do we do? We've already signed on with TypeScript...

EmberJS may internally rely on TypeScript, but it doesn't need to; if this RFC merely asks to document TypeScript usage on the main EmberJS website, I have some qualms, but far less than if it becomes part of the standard blueprint.

Types Solve Everything

Types don't solve everything. As this isn't a debate on to TypeScript or not to TypeScript, strictly for documentation purposes, then sure, continue to use TypeScript internally. For documentation purposes and autocomplete, of course tooling will be better for a commercially-backed IDE that grandfathered TypeScript.

To Tool or Not to Tool

I agree that falling prey to the Bandwagon Effect often results in technical debt. Technical debt. A lof of us have settled on Ember because it deviates from the norm of "put everything in one file" and "pick your own router solution". A developer survey also shows that far more developers choose competing technologies like React and Vue because of their simplicity and ease of use (with a simple <script> tag in a normal HTML document that is). Does that mean that we should turn our backs and abandon Ember?

The discussion, rather, seems to focus on whether we should adopt TypeScript as a first-class citizen.

For documentation purposes, this makes sense. From a beginner's perspective, it doesn't.

My Bad Blood With TypeScript

This discussion doesn't aim to talk about to to TypeScript or not to TypeScript, so I'll keep this to a minimum:

I spent a year working full-time on a TypeScript project in Angular 2. At the end of it, it felt refreshing to return to writing "plain" JS in Ember where I didn't have to declare types after every variable or function declaration. I realized, at the end of my one-year love affair with Angular, that part of JavaScript's beauty lies in its ducktyping; in other words, advanced usage of .call and Number allow us to cast reliably, and much of JavaScript's "magic" makes it desirable rather than an enemy. Maybe the tooling has improved since 2018, but we definitely had issues with types in some cases (not all but some).

Every tool poses its merits and issues. In this case, TypeScript imposes yet another learning hurdle for newcomers. For that reason, I vote...

Passadina, katrina

  • Erlich Bachman, Silicon Valley

@jamescdavis
Copy link
Contributor

@srsgores I think the thing you may be missing is that this RFC does not propose changing the default Ember developer experience (and, in fact, it explicitly says we should not). As an Ember developer, you will not be required to think about TypeScript at all if you don't want to. Everything TypeScript-related would be opt-in, including blueprints and docs. Right now, a developer doesn't need to even be aware of TypeScript to use Ember. This would not change.

@kellyselden
Copy link
Member

This seems like all upside. The only downside is contributor burden, but I can assume that those people are already proponents of TS. So this doesn't seem controversial at all to me.

@c69-addepar
Copy link

Ember is the only major modern UI framework that does not support TypeScript. Hacking our way through JSDoc and @typedef import is a lot of pain, and and the tooling/autocomplete is very missing compared to Angular/React/Vue.

This RFC is a move in the right direction, and while of course there will still be some gaps (eg: computed properties string-based DSL) - this RFC will extend the lifetime and viability of Ember as a framework, and improve developer satisfaction.

p.s.: agree on added contributor burden, but without this change - there will be nowhere for them to contribute. 🦕 ☄️

@wycats
Copy link
Member

wycats commented Mar 16, 2021

@c69-addepar said:

Ember is the only major modern UI framework that does not support TypeScript.

TL;DR Before this RFC, the Ember TypeScript team, working loosely with the Ember Core Framework team, maintained a high level of TypeScript support in Ember. Many people make use of the extremely high-quality work of the Ember TypeScript team. Because of this, this RFC proposes that the Ember Core Framework team should take official responsibility for Ember's TypeScript support, and offer official stability guarantees around TypeScript support.


I just wanted to clarify something, since this is a common source of confusion. Today, Ember apps can and do use TypeScript, using ember-cli-typescript. The frontend of my product (https://www.skylight.io/), which is written in Ember, migrated to TypeScript in 2020. One of our engineers, Krystan Huffmenne, is giving a talk at EmberConf this year about building confidence in your code by using TypeScript in your Ember app.

Together with the Ember TypeScript team, @chriskrycho (one of the authors of this RFC) has provided support for TypeScript in Ember for quite some time. The ember-cli-typescript package is quite popular on npm (https://www.npmjs.com/package/ember-cli-typescript reports 434k weekly downloads).

Notably, the Ember TypeScript team has participated in the normal Ember evolution process. In addition to providing a clear upgrade path for ember-cli-typescript users as they have evolved support, they also support Ember's own evolution, carefully tracking new RFCs, polyfills, and features behind feature flags so that their externally-maintained types track new Ember features.

Their support includes Ember's core packages itself, as well as Ember Data, RSVP, and Ember Test Helpers (documented in their installation guide). In addition, ember-cli-typescript enhances Ember's built-in blueprints to generate TypeScript versions of the blueprints supplied by Ember. Their website also comprehensively documents the use of TypeScript with Ember's core framework concepts, as well as Ember Data.

That current status compares favorably to React, which also has externally maintained types (like Ember, you install the React types through an @types namespace). React's official documentation offers different options for statically type checking React apps. While there are many library-specific guides for using TypeScript together with important parts of the React ecosystem, and TypeScript's official documentation provide some guidance, there is no single, canonical, comprehensive guide for using TypeScript with React and its most popular components.

But don't get me wrong! In practice, React applications can successfully use TypeScript, and much of the React ecosystem treats TypeScript support as an important priority. This means that even though the React team does not maintain React's types, and even though there is no canonical guide for using React with TypeScript, we can say that React has first-class TypeScript support. There's no question about that.

This RFC proposes that the Ember Core Framework team should offer semantic versioning stability guarantees for TypeScript, just as it does for Ember's JavaScript code. This goes beyond what React does, and by formalizing a definition for what semantic versioning will mean for Ember's types, goes beyond what most other frameworks do right now.

Previous wording here could be (mis)read to take this as implying that
our support is subpar or "second-class" despite its being hgih-quality
and comparable to the state of much of the rest of the front end
ecosystem (ahead in some ways, behind in others). This small revision
clarifies that, by emphasizing the pieces we *want* to emphasize: making
support an official policy, and bringing it within the Framework core
umbrella.
@MrChocolatine
Copy link
Contributor

It is very nice you published this RFC @chriskrycho and I can't +1 enough to take this direction, thank you.

I cannot respond to all the messages I have read but for most of them I agree. Especially when it comes to reducing the gap with the other frameworks like React, Angular etc.

Ton of work ahead will there be, if this proposition lands.

@rtablada
Copy link
Contributor

This is awesome! I love this idea to have official support and guidelines + docs.

On the site docs side of things I do wonder if there's some sort of babel transform that will let us strip out the TS types (AFAIK that's the main sytax difference between ES Next and TS at this point for what we'd use in the dock).

@chriskrycho
Copy link
Contributor Author

@rtablada yeah, there are definitely some good options in that space—

  • first, Babel itself absolutely handles this; in fact, that's how TypeScript itself gets compiled into Ember apps and addons today: using the Babel TS plugin
  • second, for a lot of the API docs stuff, API Extractor is apt to be a very useful tool

I've intentionally left those as details to hash out in the associated RFCs, though! (Speaking of which: I’ll be opening one of the RFCs—not one of the docs ones!—in the next couple days. 😅)

chriskrycho added a commit to chriskrycho/ember-rfcs that referenced this pull request Mar 23, 2021
This RFC proposes a definition of [Semantic Versioning][semver] for
managing changes to TypeScript types, including when the TypeScript
compiler makes breaking changes in its type-checking and type emit
across a “minor”release.(Note that this RFC addresses *only* type
checking and type emit, *no t* the “transpilation”mode of the TypeScript
compiler.)

[semver]: https://semver.org

While this RFC is being authored in the context of Ember.js’ [adoption
of TypeScript as a first-cl ass supported language][RFC], its
recommendations are intentionally general, in hopes that th ese
recommendations can be widely adopted by the broader TypeScript
community.

[RFC]: emberjs#724
chriskrycho added a commit to chriskrycho/ember-rfcs that referenced this pull request Mar 23, 2021
This RFC proposes a definition of [Semantic Versioning][semver] for
managing changes to TypeScript types, including when the TypeScript
compiler makes breaking changes in its type-checking and type emit
across a “minor”release.(Note that this RFC addresses *only* type
checking and type emit, *no t* the “transpilation”mode of the TypeScript
compiler.)

[semver]: https://semver.org

While this RFC is being authored in the context of Ember.js’ [adoption
of TypeScript as a first-cl ass supported language][RFC], its
recommendations are intentionally general, in hopes that th ese
recommendations can be widely adopted by the broader TypeScript
community.

[RFC]: emberjs#724
@MelSumner
Copy link
Contributor

MelSumner commented Jun 1, 2021

Re-reading these (TS related RFCs) and have a question about this @wycats comment:

this RFC proposes that the Ember Core Framework team should take official responsibility for Ember's TypeScript support, and offer official stability guarantees around TypeScript support.

Has TypeScript itself stabilized enough for us to do this? I observe everyone already being stretched pretty thin as it is.

To be clear I don't object to the idea of it; I am concerned about the practical implementation. I think it would call for some more strategic conversations to happen first.

@pzuraq
Copy link
Contributor

pzuraq commented Jun 1, 2021

@MelSumner I can't speak to the TS roadmap personally, I'm not really keeping updated with new features and things they're focusing on, but anecdotally I can say that in the past year or so upgrades have gotten much better overall. We have experienced much less churn in the Glimmer VM and Ember codebases, and it does feel like there's more stability and changes are now more incremental.

I also think that this is not exactly a zero-sum situation. Adding support for TS will mean we need to consider types when we build and maintain APIs, but we already do that for all new APIs and most existing ones, just not publicly. There's also a pretty large amount of duplicate work by the Typed Ember team and community to maintain the Definitely Typed types in parallel with our internal types. Every API is duplicated currently, and oftentimes there are mistakes that lead to even more maintenance cost overall. Adding support for TS in the framework would mean that those community members could start contributing to the main codebase instead of the duplicate types, so we would effectively have more core contributors overall to help us keep up with the additional work load.

I think the biggest area of risk is if we need to maintain multiple TypeScript versions for a long period of time, due to some breakage from TS. We can minimize this risk, but it will always be present, and that could add a lot of maintenance cost. That's why I think the rolling-support-window support policy makes the most sense for Ember itself. This would ensure our users would always be able to upgrade TS independently of Ember, from LTS to LTS, and that we would at most have to maintain 1-2 old TS versions for a finite window of time before being able to drop support. This would be much better than the current state of types for TS developers, and would minimize the impact TS support would have on the core team and development process.

@MelSumner
Copy link
Contributor

@pzuraq okay, that makes sense; thanks for clarifying! 👍

@rwjblue
Copy link
Member

rwjblue commented Feb 18, 2022

This has been lingering a little bit, but the core team finally discussed it at todays meeting. We are all in favor of moving forward here, and are moving this into Final Comment Period. 🎉

@leepfrog
Copy link

leepfrog commented Feb 18, 2022

I've been using ember-cli-typescript for a few years now, and while it's been good, I think this RFC addresses outstanding pain-points for new projects and maintenance on existing projects.

I can't +1 enough!

@rwjblue rwjblue merged commit 7c2e7eb into emberjs:master Mar 4, 2022
@chriskrycho chriskrycho deleted the intent-to-ts branch March 4, 2022 19:11
chriskrycho added a commit that referenced this pull request Mar 24, 2022
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*.
wagenet added a commit that referenced this pull request Aug 24, 2023
Advance RFC #724 "Official TypeScript support" to Stage Ready for Release
wagenet added a commit that referenced this pull request Aug 24, 2023
Advance RFC #724 `"Official TypeScript Support"` to Stage Released
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Final Comment Period T-infrastructure T-Tooling RFCs that impact tooling, like Ember Inspector
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet