Skip to content

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

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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.

# for free to join this conversation on GitHub. Already have an account? # 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