When resolving type reference directive use baseUrl and other resolution settings#39646
When resolving type reference directive use baseUrl and other resolution settings#39646sheetalkamat wants to merge 5 commits intomasterfrom
Conversation
….d.ts and not original source file) since they are rewritten in the .d.ts emit
…ings eg. baseUrl Fixes #37928
|
@RyanCavanaugh @weswigham @DanielRosenwasser can you please comment on what you think is better approach. Does declaration emit need to be better (use relative paths when file is referenced through tree of relative paths.. Old branhc for this which doesnt handle tree case https://github.com/microsoft/TypeScript/compare/experimentRelativePaths ) or resolution which this PR tries to fix? |
|
I think we should, generally speaking, strive to make declaration emit use "the most portable" paths for things (certainly, emitting things which only work with a specific compiler option configuration isn't very portable). |
|
|
||
|
|
||
| //// [/src/solution/lib/src/common/nominal.d.ts] | ||
| /// <reference types="types" /> |
There was a problem hiding this comment.
Shouldn't it be reference path instead? How <reference types="types" /> will be resolved by another project referencing to this one? I mean, afaik reference types means "load types from types-like package (from both typesRoot or node_modules/@types) with specific name", but this is the local file, why we should refer to it with types instead of path?
This one ensures that we resolve type reference directive with baseUrl since #32878 started using
baseUrlconsiderations to generate///<reference typesinstead of ```///<reference path` and accounting for baseUrlThis is one possible fix for the issue wherein we use baseUrl when resolving type reference name.
Other could be to generate
///<reference pathwhen file is referenced only throught ```//reference path` and relative import path tree from root file.Possibly Fixes #37928