Fix wildcard export target containment in auto-imports

[scarab-systems]

Fixes #63499.

Summary

This applies the existing invalid package-json export target segment check before wildcard export targets enumerate files for auto-import entrypoint discovery.

The non-wildcard path already rejected target segments such as .., ., and node_modules. The wildcard path could call readDirectory before applying equivalent containment validation. This PR shares the existing check between those paths.

It also adds an auto-import provider regression test proving a wildcard export target that traverses outside the package does not surface an out-of-package declaration as a package auto-import completion.

Contribution note

I saw the current contribution guidance that most code changes should go to microsoft/typescript-go. I am opening this as a draft against this repo because the issue is filed here and this code path is present here. If maintainers prefer, I can close this and port the same narrow fix/test to microsoft/typescript-go.

Validation

• npx hereby runtests --tests=autoImportProvider
• npx hereby local
• npx hereby lint
• git diff --check

AI assistance disclosure

This patch was prepared with Codex assistance for this specific issue and reviewed locally before submission.

[scarab-systems]

@microsoft-github-policy-service agree

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds validation to prevent indexing/export resolution from following package.json export targets that would escape a package’s directory, and covers it with a new tsserver auto-import regression test.

Changes:

• Added a unit test ensuring wildcard export targets outside a package aren’t indexed for auto-imports.
• Centralized export-target segment validation in module resolution to reject .., ., and node_modules path segments.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/testRunner/unittests/tsserver/autoImportProvider.ts	Adds a regression test verifying no auto-import is suggested from an export target that escapes the package directory.
src/compiler/moduleNameResolver.ts	Introduces shared validation for export-map targets to block unsafe path segments before indexing/resolving entrypoints.

[scarab-systems]

Thanks — I updated the PR to address the review feedback and force-pushed the amended commit.

I reviewed the changes after the update and reran the relevant validation locally:

• npx hereby runtests --tests=autoImportProvider
• npx hereby local
• npx hereby lint
• git diff --check

The scope is still limited to applying the existing invalid package-json export target segment check before wildcard export targets enumerate files for auto-import entrypoint discovery, plus the focused auto-import provider regression test.

Happy to make any further adjustments if maintainers prefer this shaped differently or ported to microsoft/typescript-go.

[RyanCavanaugh]

Thanks for the disclosures. Honestly, I'm not sure how to be more clear that this repo isn't accepting new dev contributions unless they meet the 6.0 critical patch bar. Any ideas?

[scarab-systems]

Understood — thanks for clarifying.

I opened this here because the issue was filed in this repo and the matching code path still exists here, but I understand now that this does not meet the current 6.0 critical patch bar for new dev contributions.

I’ll close this PR rather than create more triage noise. If this issue should be revisited in microsoft/typescript-go instead, I can take that direction separately only if maintainers want it.

Thanks for taking a look.

[scarab-systems]

Understood, and thanks for clarifying. I misunderstood the repo posture because the issue and affected implementation are still present here, but I understand now that this does not meet the 6.0 critical patch bar for this repository.\n\nI’ll close this PR and won’t open further dev PRs against this repo unless a maintainer explicitly indicates the change meets that bar.\n\nSince you asked: the process idea I’d offer is making the PR template or policy bot state that new dev PRs to this repo are only reviewed when maintainer-requested or explicitly qualifying as 6.0 critical patches; otherwise contributors should close without review. That would have made the expected action clearer to me.\n\nThanks again.