-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
[QUEST] RFC 800: TypeScript Adoption Plan Implementation Tracking #20162
Comments
FYI, the |
@chriskrycho Seems like a part is missing from the |
Oh, good catches on both points. Updating! |
@chriskrycho @bertdeblock I'd like to help out with I think we need to first update the repo (CI, dependencies, and minimum support for Node & Ember), before we introduce TypeScript, though. This would help with future maintenance. Is it okay if I temporarily own the project and make a few pull requests to keep the project up-to-date and easy to maintain? |
Please do! I'll mark is at "taken" here and am happy to help with any TS work there. |
@chriskrycho Thanks! |
@emberjs/typescript-core Can this be closed? |
I think we've completed the high-priority items on this list but not everything. Checking in with @wagenet |
RFC 0800 Tracking Issue
Implement RFC 0800: TypeScript Adoption Plan.
Enable TS blueprints
EMBER_TYPESCRIPT_BLUEPRINTS
flag #20352Publish types
We do not need to publish types for every package in Ember's dependencies—only for the packages which are part of its programmatic public APIs. An example of a dependency we don’t need to ship types with:
ember-cli-dependency-checker
is integrated into the classic Ember CLI build pipeline, but it doesn’t expose any APIs for users to call. The following list is comprised of the items in the default blueprints filtered for that criteria.These items will be checked off if they have been "claimed"—please comment if you'd like to claim one! We will track their status via links to the issues/PRs which implement them.
Status: Last updated 2022/12/13, with the dependencies from the app and v1 addon blueprints.
ember-source
(i.e. Ember.js)ember-data
, including:ember-data
@ember-data/adapter
@ember-data/canary-features
@ember-data/debug
@ember-data/deprecations
@ember-data/model
@ember-data/record-data
@ember-data/serializer
@ember-data/store
@ember/optional-features
: Convert to TS or supply ambient definitions ember-optional-features#329@ember/test-helpers
: Convert to TS or supply ambient definitions ember-test-helpers#1268@glimmer/component
– what we ship here is actually somewhat wrong, but not in a blocking way@glimmer/tracking
– what we ship here is actually right from a TS POV (unlike the runtime POV!)ember-auto-import
– already ships types 🎉ember-cli
: Convert to TS or supply ambient definitions ember-cli/ember-cli#9996ember-cli-app-version
ember-cli-babel
ember-cli-htmlbars
: Convert to TS or supply ambient definitions ember-cli/ember-cli-htmlbars#753ember-cli-inject-live-reload
ember-cli-terser
ember-fetch
– Note: this one is complicated. It already ships types, but badly. Please extra reach out if you pick this one up: a path forward exists but isn't necessarily obvious!ember-load-initializers
– already ships types! 🎉ember-page-title
: Convert to TS or supply ambient definitions ember-cli/ember-page-title#239ember-qunit
: Convert to TS or supply ambient definitions ember-qunit#957ember-resolver
: Convert to TS or supply ambient definitions ember-cli/ember-resolver#795ember-template-lint
ember-welcome-page
: Convert to TS or supply ambient type definitions ember-cli/ember-welcome-page#387loader.js
1qunit
– has reasonably-good types (which we help maintain) on DefinitelyTyped and is not a package we controlqunit-dom
– already ships types! 🎉Footnotes
Debatably, anyway: we could work on dropping this instead, and its public API usage is intended to be minimal; but right now it is a public API. ↩
The text was updated successfully, but these errors were encountered: