MCPcopy Index your code
hub / github.com/nodejs/node / resolveTypeReferenceDirective

Function resolveTypeReferenceDirective

test/fixtures/snapshot/typescript.js:42536–42683  ·  view source on GitHub ↗

* @param {string | undefined} containingFile - file that contains type reference directive, can be undefined if containing file is unknown. * This is possible in case if resolution is performed for directives specified via 'types' parameter. In this case initial path for secondary lookups

(typeReferenceDirectiveName, containingFile, options, host, redirectedReference, cache, resolutionMode)

Source from the content-addressed store, hash-verified

42534 * is assumed to be the same as root directory of the project.
42535 */
42536 function resolveTypeReferenceDirective(typeReferenceDirectiveName, containingFile, options, host, redirectedReference, cache, resolutionMode) {
42537 ts.Debug.assert(typeof typeReferenceDirectiveName === "string", "Non-string value passed to `ts.resolveTypeReferenceDirective`, likely by a wrapping package working with an outdated `resolveTypeReferenceDirectives` signature. This is probably not a problem in TS itself.");
42538 var traceEnabled = isTraceEnabled(options, host);
42539 if (redirectedReference) {
42540 options = redirectedReference.commandLine.options;
42541 }
42542 var containingDirectory = containingFile ? ts.getDirectoryPath(containingFile) : undefined;
42543 var perFolderCache = containingDirectory ? cache && cache.getOrCreateCacheForDirectory(containingDirectory, redirectedReference) : undefined;
42544 var result = perFolderCache && perFolderCache.get(typeReferenceDirectiveName, /*mode*/ resolutionMode);
42545 if (result) {
42546 if (traceEnabled) {
42547 trace(host, ts.Diagnostics.Resolving_type_reference_directive_0_containing_file_1, typeReferenceDirectiveName, containingFile);
42548 if (redirectedReference)
42549 trace(host, ts.Diagnostics.Using_compiler_options_of_project_reference_redirect_0, redirectedReference.sourceFile.fileName);
42550 trace(host, ts.Diagnostics.Resolution_for_type_reference_directive_0_was_found_in_cache_from_location_1, typeReferenceDirectiveName, containingDirectory);
42551 traceResult(result);
42552 }
42553 return result;
42554 }
42555 var typeRoots = getEffectiveTypeRoots(options, host);
42556 if (traceEnabled) {
42557 if (containingFile === undefined) {
42558 if (typeRoots === undefined) {
42559 trace(host, ts.Diagnostics.Resolving_type_reference_directive_0_containing_file_not_set_root_directory_not_set, typeReferenceDirectiveName);
42560 }
42561 else {
42562 trace(host, ts.Diagnostics.Resolving_type_reference_directive_0_containing_file_not_set_root_directory_1, typeReferenceDirectiveName, typeRoots);
42563 }
42564 }
42565 else {
42566 if (typeRoots === undefined) {
42567 trace(host, ts.Diagnostics.Resolving_type_reference_directive_0_containing_file_1_root_directory_not_set, typeReferenceDirectiveName, containingFile);
42568 }
42569 else {
42570 trace(host, ts.Diagnostics.Resolving_type_reference_directive_0_containing_file_1_root_directory_2, typeReferenceDirectiveName, containingFile, typeRoots);
42571 }
42572 }
42573 if (redirectedReference) {
42574 trace(host, ts.Diagnostics.Using_compiler_options_of_project_reference_redirect_0, redirectedReference.sourceFile.fileName);
42575 }
42576 }
42577 var failedLookupLocations = [];
42578 var features = getDefaultNodeResolutionFeatures(options);
42579 // Unlike `import` statements, whose mode-calculating APIs are all guaranteed to return `undefined` if we're in an un-mode-ed module resolution
42580 // setting, type references will return their target mode regardless of options because of how the parser works, so we guard against the mode being
42581 // set in a non-modal module resolution setting here. Do note that our behavior is not particularly well defined when these mode-overriding imports
42582 // are present in a non-modal project; while in theory we'd like to either ignore the mode or provide faithful modern resolution, depending on what we feel is best,
42583 // in practice, not every cache has the options available to intelligently make the choice to ignore the mode request, and it's unclear how modern "faithful modern
42584 // resolution" should be (`node16`? `nodenext`?). As such, witnessing a mode-overriding triple-slash reference in a non-modal module resolution
42585 // context should _probably_ be an error - and that should likely be handled by the `Program` (which is what we do).
42586 if (resolutionMode === ts.ModuleKind.ESNext && (ts.getEmitModuleResolutionKind(options) === ts.ModuleResolutionKind.Node16 || ts.getEmitModuleResolutionKind(options) === ts.ModuleResolutionKind.NodeNext)) {
42587 features |= NodeResolutionFeatures.EsmMode;
42588 }
42589 var conditions = features & NodeResolutionFeatures.Exports ? features & NodeResolutionFeatures.EsmMode ? ["node", "import", "types"] : ["node", "require", "types"] : [];
42590 var diagnostics = [];
42591 var moduleResolutionState = {
42592 compilerOptions: options,
42593 host: host,

Callers

nothing calls this directly

Calls 14

isTraceEnabledFunction · 0.85
traceFunction · 0.85
traceResultFunction · 0.85
getEffectiveTypeRootsFunction · 0.85
primaryLookupFunction · 0.85
secondaryLookupFunction · 0.85
realPathFunction · 0.85
arePathsEqualFunction · 0.85
pathContainsNodeModulesFunction · 0.85
assertMethod · 0.80
getMethod · 0.65

Tested by

no test coverage detected

Used in the wild real call sites across dependent graphs

searching dependent graphs…