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

[TS 4.5-dev] Regression: Promise.all -- "Expected 1 type arguments, but got 2" #46651

Closed
eamodio opened this issue Nov 3, 2021 · 4 comments
Closed
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@eamodio
Copy link

eamodio commented Nov 3, 2021

Bug Report

It seems some Promise.all inferencing has changed in 4.5., as I have some patterns in GitLens where I am building an array in the call to Promise.all where some of the promises might be undefined. And in TS 4.5. I now get a Expected 1 type arguments, but got 2 error.

🔎 Search Terms

🕗 Version & Regression Information

  • This is a crash
  • This changed between versions 4.4.4 and 4.5-beta and still present in 4.6.0-dev.20211102.
  • This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
  • I was unable to test this on prior versions because _______

⏯ Playground Link

Playground link with relevant code

💻 Code

interface GitBranch { type: 'branch' }

interface GitTag {  type: 'tag' }

async function getBranches(): Promise<GitBranch[]> {
	return undefined!;
}

async function getTags(): Promise<GitTag[]> {
	return undefined!;
}

async function getBranchesOrTags(include?: 'all' | 'branches' | 'tags') {
	const [branches, tags] = await Promise.all<GitBranch[] | undefined, GitTag[] | undefined>([
		include == null || include === 'all' || include === 'branches'
			? getBranches()
			: undefined,
		include == null || include === 'all' || include === 'tags'
			? getTags()
			: undefined,
	]);

	branches;
	tags;
}
Output
"use strict";
async function getBranches() {
    return undefined;
}
async function getTags() {
    return undefined;
}
async function getBranchesOrTags(include) {
    const [branches, tags] = await Promise.all([
        include == null || include === 'all' || include === 'branches'
            ? getBranches()
            : undefined,
        include == null || include === 'all' || include === 'tags'
            ? getTags()
            : undefined,
    ]);
    branches;
    tags;
}
Compiler Options
{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "alwaysStrict": true,
    "esModuleInterop": true,
    "declaration": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "target": "ES2017",
    "jsx": "react",
    "module": "ESNext",
    "moduleResolution": "node"
  }
}

🙁 Actual behavior

Got Expected 1 type arguments, but got 2 on the Promise.all call.

🙂 Expected behavior

No errors like in TS 4.4.4 and prior

@eamodio
Copy link
Author

eamodio commented Nov 3, 2021

I did just notice that if I remove the <GitBranch[] | undefined, GitTag[] | undefined> from the Promise.all call, it gets inferred correctly.

@IllusionMH
Copy link
Contributor

Another way is to specify types that you have in arguments.
Promise.all<[Promise<GitBranch[]> | undefined, Promise<GitTag[]> | undefined]> then first overload will be used.

Playground

@andrewbranch andrewbranch added the Working as Intended The behavior described is the intended behavior; this is not a bug label Nov 3, 2021
@andrewbranch
Copy link
Member

Maybe we should call this out more explicitly in the stable blog post. There’s a section about the broader Promise/Awaited changes but the type parameter change isn’t specifically mentioned.

@typescript-bot
Copy link
Collaborator

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

4 participants