Skip to content

Port TypeScript PR #60083: Don't issue implicit any when obtaining the implied type for a binding pattern #1120

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

Closed
wants to merge 2 commits into from

Conversation

Copilot
Copy link
Contributor

@Copilot Copilot AI commented Jun 9, 2025

This PR ports TypeScript PR #60083 to prevent inappropriate implicit any errors when obtaining the implied type for binding patterns in destructuring scenarios.

Problem

Previously, binding patterns in destructuring parameter declarations would incorrectly trigger implicit any errors, even when the types could be properly inferred from context. For example:

/**
 * @param {Object} [config]
 * @param {Partial<Record<'json' | 'jsonc' | 'json5', string[]>>} [config.additionalFiles]
 */
export function prepareConfig({
    additionalFiles: {
        json = []  // ❌ Error: Binding element 'json' implicitly has an 'any[]' type
    } = {}
} = {}) {
    json // Should be inferred as string[]
}

Solution

The fix separates the core type widening logic from implicit any reporting by:

  1. Extracting core logic: Created new function getWidenedLiteralTypeForInitializer that contains only the type widening logic without implicit any reporting
  2. Updating existing function: Modified widenTypeInferredFromInitializer to delegate to the new function
  3. Using appropriate function: Updated getTypeFromBindingElement to call getWidenedLiteralTypeForInitializer directly when obtaining implied types for binding patterns

Changes Made

  • Added getWidenedLiteralTypeForInitializer() function in internal/checker/checker.go
  • Updated widenTypeInferredFromInitializer() to use the new function
  • Modified getTypeFromBindingElement() to call the new function for binding pattern type inference

Testing

All existing tests pass, including the specific test cases from the original TypeScript issue:

  • destructuringParameterDeclaration9 (JavaScript with JSDoc types)
  • destructuringParameterDeclaration10 (TypeScript with explicit types)

The fix correctly removes the inappropriate implicit any errors while preserving proper type inference and other error reporting.

Fixes #1116.


💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

…plied type for binding pattern

Co-authored-by: andrewbranch <[email protected]>
@Copilot Copilot AI changed the title [WIP] Port TypeScript PR #60083: Don't issue implicit any when obtaining the implied type for a binding pattern Port TypeScript PR #60083: Don't issue implicit any when obtaining the implied type for a binding pattern Jun 9, 2025
@Copilot Copilot AI requested a review from andrewbranch June 9, 2025 22:58
Copilot finished work on behalf of andrewbranch June 9, 2025 22:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Port TypeScript PR #60083: Don't issue implicit any when obtaining the implied type for a binding pattern
2 participants