Add tsconfig path resolution following Node's semantics

[dmitrivMS]

Fixes #276592

[Copilot]

Pull request overview

This PR implements Node.js package.json exports field resolution for TypeScript configuration file path resolution, following the official Node.js ESM resolution algorithm. This enables VS Code to correctly resolve tsconfig.json extends paths when packages use conditional exports or subpath patterns, matching the behavior of Node.js and TypeScript.

Key Changes

• Added a complete implementation of Node.js package exports resolution algorithm with support for conditional exports, wildcard patterns, and array fallbacks
• Integrated exports resolution into the existing tsconfig path resolution flow, attempting exports-based resolution before falling back to traditional node_modules resolution
• Included comprehensive unit and integration tests to verify correctness against Node.js specification

Reviewed changes

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

File	Description
extensions/typescript-language-features/src/utils/packageExports.ts	New file implementing the Node.js package exports resolution algorithm with functions for pattern matching, conditional resolution, and validation according to Node.js spec
extensions/typescript-language-features/src/languageFeatures/tsconfig.ts	Adds exports-based module resolution functions (parseNodeModuleSpecifier, findNodeModulePackageRoot, tryReadPackageJson, resolveNodeModulePathUsingExports) and integrates them into getTsconfigPath
extensions/typescript-language-features/src/test/unit/packageExports.test.ts	New unit tests for the core exports resolution algorithm covering exact matches, wildcards, conditionals, arrays, null exclusions, and validation edge cases
extensions/typescript-language-features/src/test/unit/tsconfigExportsResolver.test.ts	New integration tests using the VS Code file system API to test end-to-end resolution with actual package.json files and node_modules structure

[mjbvz]

Thanks for looking into this!

I agree it's a lot of code for a smaller bug. Let me try reaching out to TypeScript to see if they would like to take ownership of tsconfig intellisense with TS-go. That would likely provide the best user experience since it would exactly match how TS resolves these files

[mjbvz]

If the tests need to use the file system, can we mock it out instead? I've found using the real FS is a very common source of flaky tests and slowness

[dmitrivMS]

Mocking the FS here is quite some work since TestFS does not appear to be available in extension tests. I can do this, but would like to confirm this will be going in.