-
Notifications
You must be signed in to change notification settings - Fork 12.8k
API: incorrect declarations in types.ts #24706
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I agree. I mentioned it on the PR. Now that we've done the bulk of the changes, we should fix one at a time and introduce helpers to help the pain. |
@RyanCavanaugh Do you plan to fix this in the near future? It's a real PITA for me as I use TypeScript's API a lot. |
repro case for // src/index.ts
export type NumberDict = { [k: string]: number }; // analyze.js
const ts = require('typescript');
const program = ts.createProgram(['src/index.ts'], {
target: ts.ScriptTarget.ES2015,
noEmit: true,
strict: true
});
const checker = program.getTypeChecker();
// get the file
const [indexFile] = program.getSourceFiles().filter(f => !f.isDeclarationFile);
// file's symbol
const indexFileSymbol = checker.getSymbolAtLocation(indexFile);
// file's exports
const { exports: exportSymbols } = indexFileSymbol;
// first exported symbol from the file
const firstExport = exportSymbols.values().next().value;
console.log(
'First symbol has type of',
checker.typeToString(checker.getDeclaredTypeOfSymbol(firstExport)),
'and it has a valueDeclaration of',
firstExport.valueDeclaration
); Result: of
|
We just ran into this bug in Related issues: |
TypeScript doesn't enforce strict non-null checks inside the compiler, so we should. Perform a non-null check on symbol value declarations, which are typed as always existing but don't exist for type-only values like interfaces. See microsoft/TypeScript#24706
@weswigham @RyanCavanaugh will you accept changes fixing this? |
… avoid error if base class has no value declaration The undecorated-classes-with-decorated-fields migration relies on the type checker to resolve base classes of individual classes. It could happen that resolved base classes have no value declaration. e.g. if they are declared through an interface in the default types. Currently the migration will throw in such situations because it assumes that `ts.Symbol#valueDeclaration` is always present. This is not the case, but we don't get good type-checking here due to a bug in the TypeScript types. See: microsoft/TypeScript#24706. Fixes angular#36522.
`compiler/types.ts` uses some non-nullable typings to avoid frequent assertions in the TS compiler. This causes a loss of type information and makes using typescript's public API dangerous since an external consumer may assume that a certain type is defined when it is not. (See microsoft#24706 for more details). One such case is `Symbol#valueDeclaration`, which this PR provides a public API typing fix for. This is implemented by adding an additional processing step to the LGK compiler that overwrites definitions with the `@optional` JSDoc tag to include the `?` token in their signature. Specifically, `/** @optional */ valueDeclaration: Declaration` -> `valueDeclaration?: Declaration`. The relevant change in the public API definitions is at lib/typescript.d.ts:2285. Part of microsoft#24706
… avoid error if base class has no value declaration (#36543) The undecorated-classes-with-decorated-fields migration relies on the type checker to resolve base classes of individual classes. It could happen that resolved base classes have no value declaration. e.g. if they are declared through an interface in the default types. Currently the migration will throw in such situations because it assumes that `ts.Symbol#valueDeclaration` is always present. This is not the case, but we don't get good type-checking here due to a bug in the TypeScript types. See: microsoft/TypeScript#24706. Fixes #36522. PR Close #36543
… avoid error if base class has no value declaration (#36543) The undecorated-classes-with-decorated-fields migration relies on the type checker to resolve base classes of individual classes. It could happen that resolved base classes have no value declaration. e.g. if they are declared through an interface in the default types. Currently the migration will throw in such situations because it assumes that `ts.Symbol#valueDeclaration` is always present. This is not the case, but we don't get good type-checking here due to a bug in the TypeScript types. See: microsoft/TypeScript#24706. Fixes #36522. PR Close #36543
Simple lint rule to ban usage of properties that introduce bugs. microsoft/TypeScript#24706
Simple lint rule to ban usage of properties that introduce bugs. microsoft/TypeScript#24706
The
--strictNullChecks
PR changed some declarations intypes.ts
to avoid frequent assertions in the compiler's code. Unfortunately these changes make it really unsafe for API users because they no longer contain the actually nullable types: #22088 (comment) #22088 (comment)ts.Node#parent
is no longer optional (which is definitely wrong forSourceFile
)ts.Symbol#declarations
andts.Symbol.valueDeclaration
are no longer optional, but can still be undefinedts.Type#symbol
is no longer optional, but I guess this comment is still up to date:// Symbol associated with type (if any)
These changes should either be reverted or replaced in the published declaration files.
/cc @Andy-MS @weswigham
The text was updated successfully, but these errors were encountered: