Support @types, preview types, and stable types for Ember.js
#1389
Conversation
gitKrystan
changed the title
Note that there are still issues with types support for Ember 5.1, which will emberjs#1389 will address.
ember-source 5.1 is out but it cannot typecheck correctly in an apps yet due to: - emberjs/ember.js#20479 - emberjs/ember-test-helpers#1389
This introduces an intermediate module for the two `Owner`-related proxy mixins, allowing us to resolve the types for them from the various locations where they have lived on DT and in Ember. This is not great, but isolates the complexity there in a single place where we can later remove it, and makes it so consuming code can be unaware of it.
|
Thanks for working on this! |
These are unfortunately difficult/impossible to fully backport into 4.8 so just ts-ignore them for now. This is, to say the least, annoying, but it will get the job done.
chriskrycho
changed the title
@types, preview types, and stable types for Ember.js
| // SAFETY: this is always present, but only the stable type definitions from | ||
| // Ember actually preserve it, since it is private API. |
There was a problem hiding this comment.
For reference: we cannot ts-expect-error this because it actually works on the stable types. 😂
| }, | ||
| export default function buildRegistry(resolver: Resolver) { | ||
| let namespace = new Application(); | ||
| // @ts-ignore: this is actually the correcct type, but there was a typo in |
There was a problem hiding this comment.
Similarly, many of these work correctly… on some versions of Ember. I used ts-ignore here and below to make it so that if there is an error, it is suppressed :sigh: but if not, it still has type safety.
|
|
||
| // Imports from `@types` | ||
| // @ts-ignore | ||
| import type CPM_DTS from '@ember/engine/-private/container-proxy-mixin.d.ts'; |
There was a problem hiding this comment.
Can you ELI5 this?
There was a problem hiding this comment.
Roughly, it imports from all the different paths where this type can exist, using ts-ignore on all of them to make the ones which are not present on any given Ember types version still pass the type checking, and then go through these type shenanigans so that it only resolves the one that actually does exist on the current version. The net result is that whether you are using the Definitely Typed types, the 4:8 preview types, the 4.12 preview types, or the stable types, one of these will be available and the others will not, and these exports will correctly resolve only that one. If you don’t do the type level shenanigans, you end up mixing any in (since that is the type of a ts-ignored import which has no type definition at that module path), which is definitely not what we want.
Requires #1405
I was getting all sorts of tsc issues on canary builds for an addon so took a stab at resolving them. This is a bit hack-y just to identify the issues.
Currently working to reconcile these types w/ existing preview types, as they are incompatible.