Repository navigation
Nightly bug(?) with infering function generic while being part of intersection #49307
Description
Activity
Taking possible red herrings out of the repro:
// @strict: true declare function createSlice<T>( reducers: { [K: string]: (state: string) => void } & { [K in keyof T]: object } ): void; createSlice( { f(a) {} } )
aisstringin 4.7 and implicit any in 4.8 and I don't see a good reason for that to have changed.Reacted by Andrew Branch, Ethan and MeligyTypeScript Bot (@typescript-bot) bisect good v4.7.4 bad main
The change between v4.7.4 and main occurred at 9236e39.
The PR that caused the behavior change was #48668.
Taking a closer look at Ryan Cavanaugh (@RyanCavanaugh)’s simplified repro, it’s not so clear to me what the expected behavior really should be. Both before and after #48668,
Tis inferred from the mapped type to be{ f: unknown }, so the instantiated apparent type ofreducersis{ [key: string]: (state: string) => void } & { f: object }
If you wanted to say that the type of the property
fof that type wasobject & ((state: string) => void), I think that would be reasonable, but that doesn’t seem to be how we treat intersections of concrete properties and index signatures. We consistently say the type of propertyfof this type is justobject... except in this repro pre-#48668. It looks to me like the 4.7 behavior is oddly inconsistent. Even quick info has some puzzling results:
If the contextual type of
fisobject, how can the contextual type of its parameter not be an implicitany?To be clear, I don’t think the implicit
anyis desirable per se, but I think it’s consistent with the inference being made and the general behavior of getting types of concrete properties from an object intersected with an index signature. To get rid of the implicitany, I think we’d either need to- Infer
{}forT - Make
({ [k: string]: T } & { p: U })['p']→T & U
I don’t know what heuristic we could use to decide to do (1)—it seems super sketchy. (2) makes theoretical sense to me but would be a massive break and probably have tons of undesirable follow-on effects (I’m sure there’s an issue open about this).
TLDR, it’s not great that the behavior changed to introduce an error, but I can’t quite figure out why it ever worked before. Is there a logic to the past behavior I’m missing?
- Infer
A possible rebuttal of my analysis that I thought about but forgot to address: you might say that getting a property of a contextual type is fuzzier and more permissive than getting a property of that same type via something like a property access expression. For example, if I have a union type
string | { x: (state: string) => void }:type T = string | { x: (state: string) => void }; declare let a: T; a.x; // Error because `x` is not on all constituents of the union const y: T = { // `state: string` - we simply ignored the unuseful constituents when // doing the "same" operation on a contextual type x(state) {} }
However, if the only relevant distinction was "getting a property of a contextual type is not the same as getting a property of a type generally," we would expect this to work:
let x: { [key: string]: (state: string) => void } & { f: object } = { f: (a) => {} // Error: `a` is implicitly `any` };
and it does not. There is something different happening not just because there is a contextual type, but because of... well, something else around that mapped type mapping over
keyof T.Andrew and I kicked this around a while and think the right move on this particular repro is Won't Fix. Reasons for this:
- The thing that broke it changes other things in demonstrably good ways
- In the given repro, there's just no reason to write that index signature, since it only presumably subsumes the behavior of the existing typing since all functions are objects (and in cases where this is not the case, the error is correct). The one place it doesn't is symbol keys, and if you write
T in (keyof CaseReducers) & symbol]: {}, then the code works as hoped-for - We don't really know how to fix it
So anyway if you have a repro that falls under both the "intersection is necessary" and "contextual parameter inference would be sound" umbrellas, we can take a look at that in a new issue. Thanks!
12 remaining items
Hi, I'm another Redux Toolkit maintainer. Wanted to follow up on this.
Lenz has put together a potential workaround on our side, but it requires what is frankly a pretty ugly hack (a separate package that abuses
typesVersionsto figure out what TS version we're dealing with, and changing what ourcreateSlicetype includes based on that).Any thoughts on whether this issue is something the TS team intends to address before 4.8 is released?
Reacted by MeligyI've been looking at
createSlicetoday to try to figure out if there's something that can be done in userland to avoid the problem.The originating use case at #48812 is a lot more compelling due to its simplicity, but I don't like breaking Peter to fix Paul.
Ryan Cavanaugh (@RyanCavanaugh) thank you! Lenz is on vacation atm, but if you've got any questions or anything, please ping me . Appreciate you at least looking at this!
Is there a test suite or equivalent where I can try different definitions of
createSliceto make sure I'm preserving the typing of the use cases?Yeah. We have both unit tests, and a set of "type tests".
- https://github.com/reduxjs/redux-toolkit/blob/master/packages/toolkit/src/tests/createSlice.test.ts
- https://github.com/reduxjs/redux-toolkit/blob/master/packages/toolkit/src/tests/createSlice.typetest.ts
to run them:
cd packages/toolkit # Run just the createSlice unit tests yarn test createSlice.test # Run _all_ the typetests yarn type-testsReacted by Ryan CavanaughHmm, what's the current status of this particular issue? Is it considered to be a valid use case? I've found myself being somewhat confused by index signatures in more complex scenarios and I don't know how to properly reason about this.
Note that both latest reduced repros from Andrew Branch (@andrewbranch) can be fixed by using
T[K]within the mapped type's template (either by ending up with it in the conditional type there or by intersecting with it): nightly TS playgroundMateusz Burzyński (@Andarist) unfortunately, the
T[K]would breakcreateSlicein older TS versions, so it's not a fix that would work for us on it's own. So we now end up adding another conditional to decide between{}andT[K]depending on the TS version.Ryan Cavanaugh (@RyanCavanaugh) : just to check, what was the final resolution? Just a reversion of the commit that caused this breakage for us?
Since this has been fixed by reverting the other fix - could we reopen #48812 ?
Mark Erikson (@markerikson) correct - reverted in both 4.8 final and ongoing in
main. Hopefully a fix can be found that satisfies both use cases.Thank you for taking a look at this!
First of all, the title exists for the sake of a title. I don't really know exactly what is wrong with this bug. I came across this while working on something with redux tookit.
Error:
Parameter 'state' implicitly has an 'any' type.Expected:
state = WritableDraft<{username: string, isLoggedIn: true, ...}>I am using the nightly extension and the bug has not occured because of an update to redux toolkit or a change in my code, but has instead been because of typescript versions changing.
The code itself works in typescript 4.7.0 but not in typescript nightly/4.8.0
In order to create a minimum reproducible example, I have tried to simplify it as much as possible, (which was harder than I imagined). The problem is rather weird, there are multiple parts that cause this bug and removing any will fix it. However, the issue remains, version 4.7.0 works while the same on nightly errors.
At this point, I still do not know exactly what the problem is. In fact, it may even be intentional. However, this is something that breaks redux toolkit so I think the matter is something worth taking a look at.
What search terms have I used? None. I don't know how to put this bug into words.