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

[BUGFIX LTS] Backport Resolver to preview types #20318

Merged
merged 1 commit into from
Dec 9, 2022

Conversation

chriskrycho
Copy link
Contributor

@chriskrycho chriskrycho commented Dec 9, 2022

This particular type did not "land" until 4.9.0, but its absence means the preview types published on 4.8 LTS will not be usable for most Ember TS users: without this backport, ember-resolver itself cannot publish correct types until 4.10 is out, and ember-qunit requires valid types for ember-resolver, which in turn blocks people from migrating from DT types for ember-qunit until they can use the types published with ember-source. It is a type-only import that was simply missed until doing some of the follow-on work, so it is completely safe to back port.


Meta notes: I'm describing this as a "bug fix" because of a fairly complicated set of interactions that I've discovered in working through trying to solve #20254 across the ecosystem.

  1. We have the new Resolver type. It’s present on Ember 4.9+.

  2. For any part of the community to be able to move to Ember’s own types, we need ember-qunit and @ember/test-helpers to be publishing their own types. (There are others, especially Ember Data, but those are two of the biggest.) Otherwise, you end up with types for those coming from DefinitelyTyped, which are incompatible b/c of how they depend the DT definitions for e.g @ember/application types, which are, far enough down the rabbit hole, incompatible with the stable types.

  3. ember-qunit depends on the Resolver type, which its DT types currently get via @types/ember-resolver.

  4. Which means ember-qunit needs to require types published natively one way or another from ember-resolver or just use the looser (and more correct!) contract from import { Resolver } from '@ember/owner'.

  5. But for either of those to work, something has to give if folks are going to be able to use the types on 4.8 LTS:

    Either ember-resolver needs to publish its own types which are compatible, and we have to maintain that compatibility by hand until… some arbitrary point where we can say it’s reasonable to say “you must use Ember 4.9+ if you want these types,” presumably after 4.12 is out as an LTS target.

    Or we backport the Resolver bits to 4.8 LTS and call it a “bug fix” because you can’t use the preview types without it, at which point ember-resolver can say the same thing as literally the whole rest of the ecosystem: “This ships types as of vWhatever, but to use it you must use the latest 4.8 LTS Ember release to get that support.”

This PR implements the second option there, because while it’s arguable from a SemVer Lawyer™ POV, it’s the one that gives the community the best shot at actually migrating successfully.

This particular type did not "land" until 4.10.0, but its absence means
the preview types published on 4.8 LTS will not be usable for most
Ember TS users: without this backport, `ember-resolver` itself cannot
publish correct types until 4.10 is out, and `ember-qunit` requires
valid types for `ember-resolver`, which in turn blocks people from
migrating from DT types for `ember-qunit` until they can use the types
published with `ember-source`.
@chriskrycho chriskrycho added Bug TypeScript Work on Ember’s types labels Dec 9, 2022
@chadhietala chadhietala merged commit 10d37e0 into release-4-8 Dec 9, 2022
@chadhietala chadhietala deleted the backport-owner-types-only branch December 9, 2022 16:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug TypeScript Work on Ember’s types
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants