You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Resolve relative content mapper packages, always resolve from the config that declares the mapper - #65105
Content mapper entries such as "package": "../mapper" could load an ancestor’s package.json, producing misleading diagnostics or silently selecting an unrelated mapper.
Resolution: Reject relative and absolute paths before searching node_modules, reporting TS18075. Named and scoped packages retain existing behavior.
Regression coverage: Cover existing and nonexistent relative paths, absolute paths, and Windows separators with an unrelated ancestor mapper present.
CopilotAI
changed the title
[WIP] Fix content mappers loading package.json from nearest node_modules
Reject filesystem paths in content mapper package resolution
Nov 2, 2026
Copilot you're rejecting resolution without any specific config diagnostic? Just "could not be resolved"? Do you think that's a good UX? Is there any principled reason not to allow a relative/absolute path to a package directory in the first place?
Copilot you're rejecting resolution without any specific config diagnostic? Just "could not be resolved"? Do you think that's a good UX? Is there any principled reason not to allow a relative/absolut...
No—there isn’t a principled reason to prohibit directory paths, and the generic diagnostic obscured that restriction. Changed in 81140f2 to resolve relative paths from the containing config’s directory and accept absolute directory paths. Both retain manifest validation and workspace authorization; missing paths report TS18075 without falling back to an ancestor package. Added coverage for these cases, including Windows paths and authorization denial. npx hereby validate passed.
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
Inherited relative mapper paths resolve against the consuming config rather than the declaring config, potentially rejecting a valid mapper or silently loading the wrong one.
Addresses #65097’s unintended ancestor-package lookup in content mapper resolution. The implementation supports direct filesystem paths rather than rejecting them as the title and description state.
Changes:
Resolve relative and absolute package directories before searching node_modules.
Add tests for existing and missing paths, Windows separators, and workspace restrictions.
Update the resolver comment to describe directory-path support.
File
Description
tsc/internal/tsoptions/contentmappers.go
Updates the comment to describe direct path resolution.
tsc/internal/tsoptions/contentmappers_test.go
Adds filesystem-path resolution and failure cases.
tsc/internal/module/resolver.go
Resolves filesystem paths directly before package-name lookup.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
Directory mappers inside an open workspace are incorrectly rejected when external code is enabled, requiring a policy fix and regression coverage.
No open issues 🎉
1 previously missed issue
In code that hasn't changed since last review
Allow in-workspace content mapper directories
tsc/internal/module/resolver.go:544
With /home/project open and external code enabled, a mapper declared as "package": "./mapper" is still rejected in the editor as “outside the open workspace.” IsContentMapperPackageAllowed in tsc/internal/project/configfileregistrybuilder.go:798–808 rejects any directory without a node_modules component, including the in-workspace directory returned here. Update that policy to allow directory mappers inside an open workspace while retaining rejection outside it, and add a project or language-server regression test.
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
Relative symlinked mapper directories are not canonicalized, causing change notifications for the real package.json to miss the mapper manifest and leave it stale.
Copilot fix the "previously missed" comment from the review
Fixed in 121727f46: directory mappers are now allowed when their resolved path is inside an open workspace; outside-workspace directories remain denied. Added regression coverage, and npx hereby validate passes.
Andrew Branch (andrewbranch)
changed the title
Reject filesystem paths in content mapper package resolution
Resolve relative content mapper packages, always resolve from the config that declares the mapper
Nov 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Content mapper entries such as
"package": "../mapper"could load an ancestor’spackage.json, producing misleading diagnostics or silently selecting an unrelated mapper.node_modules, reporting TS18075. Named and scoped packages retain existing behavior.packagepath loads the package.json of the nearest folder with node_modules #65097