Skip to content

Compiler API: Expose More from typescript.d.ts #23719

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

Open
SlurpTheo opened this issue Apr 26, 2018 · 7 comments
Open

Compiler API: Expose More from typescript.d.ts #23719

SlurpTheo opened this issue Apr 26, 2018 · 7 comments
Labels
API Relates to the public API for TypeScript Help Wanted You can do this Suggestion An idea for TypeScript
Milestone

Comments

@SlurpTheo
Copy link

TypeScript Version: 2.9.0-dev.20180426

While Traversing the TypeScript AST of a source file, there have been a number of helpful things I've found by extending ts.* from typescript.d.ts and I would like it if these could be exposed (or not marked /* @internal */).

Search Terms:
typescript.d.ts
Node.locals
Symbol.parent
getContainingFunction
isAssignmentTarget

Code

declare namespace ts {
    interface Node {
        /* @internal */ readonly locals?: SymbolTable; // Locals associated with node (initialized by binding)
    }

    interface Symbol {
        /* @internal */ readonly parent?: Symbol; // Parent symbol
    }

    function getContainingFunction(node: Node): SignatureDeclaration | undefined;

    function isAssignmentTarget(node: Node): boolean;
}

Note:

  • Added readonly for Node#locals & Symbol#parent
  • For Symbol#parent, the goal is: given the symbol for a method (e.g., methodSymbol for Number#toString) find where that method is defined (e.g., Number)... maybe program.getTypeChecker().getSymbolAtLocation(methodSymbol.valueDeclaration.parent) is what is "supposed" to be used instead?
  • For ts.getContainingFunction() it seems more appropriate to have a return type of SignatureDeclaration | undefined instead of SignatureDeclaration

Related Issues:
#15841

@ajafff
Copy link
Contributor

ajafff commented Apr 26, 2018

There's a package that provides declarations even for the internal stuff: https://www.npmjs.com/package/byots

Regarding isAssignmentTarget: you might want to use isReassignmentTarget of my library tsutils.

@mhegazy
Copy link
Contributor

mhegazy commented Apr 26, 2018

I do not think we want to expose symbol.parent, nor locals. these are internal implementation details that we can change with no prior notice.

getContainingFunction andisAssignmentTarget are fine though. we would take a PR to expose them.

@mhegazy mhegazy added Help Wanted You can do this Suggestion An idea for TypeScript API Relates to the public API for TypeScript labels Apr 26, 2018
@mhegazy mhegazy added this to the Community milestone Apr 26, 2018
@SlurpTheo
Copy link
Author

SlurpTheo commented Apr 27, 2018

@mhegazy So instead of symbol.parent is my second note along the right plan of action (get symbol's valueDeclaration, get its parent, get its symbol)?

I'll have to dig more into why I needed node.locals sometime soon.

@mhegazy
Copy link
Contributor

mhegazy commented Apr 27, 2018

correct.

@granmoe
Copy link

granmoe commented Mar 6, 2019

Is there any reliable way to find all symbols available in module scope without using node.locals? This is what I desperately wish to do.

@RyanCavanaugh RyanCavanaugh modified the milestones: Community, Backlog Mar 7, 2019
@jirutka
Copy link

jirutka commented Oct 11, 2019

@granmoe, take a look at TypeChecker#getSymbolsInScope (you can get its instance from the program).

@Zemnmez
Copy link

Zemnmez commented Feb 8, 2020

I second symbol.parent! It's very hard to operate on symbol trees without it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Relates to the public API for TypeScript Help Wanted You can do this Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

7 participants