API: incorrect declarations in types.ts

Andy (Andrewkraft) (@Andy-MS)

The --strictNullChecks PR changed some declarations in types.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 for SourceFile)
ts.Symbol#declarations and ts.Symbol.valueDeclaration are no longer optional, but can still be undefined
ts.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 (Andrewkraft) (@Andy-MS) Wesley Wigham (@weswigham)

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.

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@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.
Is there anything I can do to help? Would you accept PRs to fix the issues listed above (probably one at a time to keep the diff small)?

repro case for ts.Symbol.valueDeclaration being undefined

// 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 node analyze.js

First symbol has type of NumberDict and it has a valueDeclaration of undefined

We just ran into this bug in @typescript-eslint. One of our rules assumed the typing was correct, causing a bug for an end user.
As an API consumer, we rely on the types to help us ensure we catch bugs at compile time, and it's counter-intuitive to handle cases that are contrary to the types.

Related issues:
typescript-eslint/typescript-eslint#498
typescript-eslint/typescript-eslint#496

fix(typescript_indexer): perform non-null check on symbol values

Wesley Wigham (@weswigham)

Wesley Wigham (@weswigham) Ryan Cavanaugh (@RyanCavanaugh) will you accept changes fixing this?

fix(core): undecorated-classes-with-decorated-fields migration should…

Make `Symbol#valueDeclaration` optional in public API

fix(core): undecorated-classes-with-decorated-fields migration should…

feat(eslint-plugin-internal): add rule no-poorly-typed-ts-props

Navigation Menu

Repository navigation

API: incorrect declarations in types.ts #24706

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

API: incorrect declarations in types.ts #24706

Description

Activity

weswigham commented on Jun 5, 2018

ajafff commented on Sep 17, 2018

mike-north commented on Jan 17, 2019

bradzacher commented on May 7, 2019

ayazhafiz commented on Aug 19, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions