-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
Make the unconstrained type parameter and {} assignability rule not apply under strictNullChecks #48366
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…pply under strictNullChecks
41b6b9f
to
de718eb
Compare
sandersn
approved these changes
Mar 21, 2022
This was referenced Mar 29, 2022
glasser
added a commit
to apollographql/apollo-server
that referenced
this pull request
Apr 11, 2022
Two things got a bit mixed together here. One is that we want the Disabled plugins to all be defined directly in plugin/index.ts, so that loading ApolloServerPluginInlineTraceDisabled does not spend time loading the protobuf library. The other thing is that we started thinking a bit more carefully about plugin context generics. We wrote some tests to make sure that you can use an `ApolloServerPlugin<BaseContext>` (ie, a plugin that doesn't need any particular fields on the context) with any `ApolloServer`, but not vice versa. As part of getting this to work, we added another `__forceTContextToBeContravariant`. We also noticed that it made more sense for BaseContext to be `{}` ("an object with no particular fields") rather than `Record<string, any>` ("an object where you can do anything with any of its fields"). We investigated whether the new contravariance annotation coming in the next two months in TS 4.7 (microsoft/TypeScript#48240) would allow us to get rid of the `__forceTContextToBeContravariant` hack and the answer is yes! However, trying `4.7.0-beta` failed for two other reasons. One is that microsoft/TypeScript#48366 required us to add some missing `extends` clauses, which we are doing now in this PR. The other is that `graphql-tools` needs some fixes to work with TS4.7 which we hope they can do soon (ardatan/graphql-tools#4381).
10 tasks
This was referenced Apr 13, 2022
1 task
This was referenced Apr 13, 2022
This was referenced Apr 13, 2022
Merged
Found |
This was referenced Apr 21, 2022
This was referenced Apr 27, 2022
Merged
1 task
This was referenced May 2, 2022
1 task
RyanCavanaugh
added a commit
to RyanCavanaugh/TypeScript
that referenced
this pull request
May 26, 2022
…pply under strictNullChecks (microsoft#48366) * Make the unconstrained type parameter and {} assignability rule not apply under strictNullChecks * Fix lint, PR feedback # Conflicts: # src/compiler/checker.ts # tests/baselines/reference/unknownType1.errors.txt
This was referenced Jun 9, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Author: Team
Breaking Change
Would introduce errors in existing code
For Milestone Bug
PRs that fix a bug with a specific milestone
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A revised version of #33570 that, per the request at the last design meeting, only removes the rule under
strictNullChecks
.Note that this does not really fix #32330 like #33570 does, because the original report does not include anything about strict mode, nor is the observed behavioral issue limited to strict mode.