Microsoft/TypeScript
Vedi su GitHubMapped types created from reverse mapped types with union/intersection constraints don't have declaration linked
Open
#57.211 aperta il 29 gen 2024
Domain: Mapped TypesHelp WantedPossible Improvement
Metriche repository
- Star
- (48.455 star)
- Metriche merge PR
- (Merge medio 6g 17h) (9 PR mergiate in 30 g)
Descrizione
🔎 Search Terms
reverse mapped type go to definition union intersection constraint declarations
🕗 Version & Regression Information
- This is the behavior in every version I tried
⏯ Playground Link
💻 Code
type StrictOptionName = "noImplicitAny" | "strictNullChecks";
interface CompilerOptions {
isolatedModules?: boolean;
noImplicitAny?: boolean;
strict?: boolean;
strictNullChecks?: boolean;
verbatimModuleSyntax?: boolean;
}
type CompilerOptionKeys = keyof {
[K in keyof CompilerOptions as string extends K ? never : K]: any;
};
declare function getStrictOptionValue(compilerOptions: CompilerOptions, flag: StrictOptionName): boolean;
declare function createComputedCompilerOptions<T extends Record<string, CompilerOptionKeys[]>>(options: {
[K in (keyof T & CompilerOptionKeys) | StrictOptionName]: {
dependencies: T[K];
computeValue: (compilerOptions: Pick<CompilerOptions, K | T[K][number]>) => Exclude<CompilerOptions[K], undefined>;
};
}): typeof options;
const computed = createComputedCompilerOptions({
isolatedModules: {
dependencies: ["verbatimModuleSyntax"],
computeValue: (compilerOptions) => {
return !!(
compilerOptions.isolatedModules || compilerOptions.verbatimModuleSyntax
);
},
},
noImplicitAny: {
dependencies: ["strict"],
computeValue: (compilerOptions) => {
return getStrictOptionValue(compilerOptions, "noImplicitAny");
},
},
strictNullChecks: {
dependencies: ["strict"],
computeValue: (compilerOptions) => {
return getStrictOptionValue(compilerOptions, "strictNullChecks");
},
},
});
const getIsIsolatedModules = computed.isolatedModules/*1*/.computeValue
🙁 Actual behavior
Go to definition doesn't go anywhere at marker 1
🙂 Expected behavior
Go to definition should go to the property at the line 21
Additional information about the issue
modifiersType for this mapped type is unknown. I think that potentially the modifiers type when iterating over any reverse mapped type (when reversed.mappedType === (mappedType.target || mappedType) could use that reversed.source as the modifiers type. If not that then at least declarations could be outsourced to that type for linking properties.