Repository navigation
spread operator infer to wrong type with method override and generic #59281
Description
🔎 Search Terms
generic spread
🕗 Version & Regression Information
- This changed on version 5.3.0-dev.20231027
⏯ Playground Link
💻 Code
type MockFactoryWithHelper<M = unknown> = (
importOriginal:<T extends M = M>() => Promise<T>
) => Partial<Record<keyof M, any>>
type PromiseMockFactoryWithHelper<M = unknown> = (
importOriginal: <T extends M = M>() => Promise<T>
) => Promise<Partial<Record<keyof M, any>>>
const util: {
mock<T>(module: Promise<T>, factory?: MockFactoryWithHelper<T>): void
mock<T>(module: Promise<T>, factory?: PromiseMockFactoryWithHelper<T>): void
} = {
mock: (() => {}) as any
};
(async function() {
util.mock(import('path'), async (importOriginal) => ({
...(await importOriginal())
}));
})();🙁 Actual behavior
Typescirpt throw error like Spread types may only be created from object types.(2698); on line spread syntax
🙂 Expected behavior
Typescirpt should not throw error on inline spread syntax.
Additional information about the issue
No response
Activity
[-]Spread syntax throw error with function override and generic[/-][+]Spread syntax throw error with method override and generic[/+]RyanCavanaugh commentedon Jul 15, 2024
The error here is because you're trying to spread a
never. This is not a syntax error.syi0808 commentedon Jul 15, 2024
But it works well on version before 5.3.0-dev.20231027. And return value of importOriginal should never be infer asnevertype.That's right. I changed the title.
syi0808 commentedon Jul 15, 2024
And if this is an unintended bug, I would love to contribute. Where can I find the changes to the 5.3.0-dev.20231027 distribution version?
[-]Spread syntax throw error with method override and generic[/-][+]spread operator infer to wrong type with method override and generic[/+]RyanCavanaugh commentedon Jul 15, 2024
every-tscan bisect to a specific commit https://github.com/jakebailey/every-tssyi0808 commentedon Jul 16, 2024
I'll try it within a week. Thanks for sharing.
Andarist commentedon Jul 16, 2024
Given that overloads are generally picked from the top to the bottom. Shouldn't this be fixed at the definition site of this
mockmethod? If you swap those overloads it works OK: TS playgroundSimilarly, it works OK if you combine those 2 overloads into a single signature: TS playground. This solution should be preferred over the first one.
RyanCavanaugh commentedon Jul 26, 2024
I agree with Mateusz Burzyński (@Andarist) 's comments in the PR - this doesn't seem like a bug.
typescript-bot commentedon Jul 29, 2024
This issue has been marked as "Not a Defect" and has seen no recent activity. It has been automatically closed for house-keeping purposes.