Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Discussion: Consider making a "shortcut" API around TypeScript for node types #6013

Closed
JoshuaKGoldberg announced in RFCs
Discussion options

Suggestion

We write code like this very frequently:

const parserServices = util.getParserServices(context);
const checker = parserServices.program.getTypeChecker();
const tsNode = parserServices.esTreeNodeToTSNodeMap.get(node);
const type = checker.getTypeAtLocation(node);

It's a little burdensome.

@bradzacher and I were chatting in a pairing about how it might be convenient to make a wrapper around this, for convenience. Vague first draft:

declare const typeUtils: {
  [K in keyof ts.TypeChecker]:
    (services: ParserServices, node: TSESTree.Node) => ReturnType<ts.TypeChecker[K]>;
};

const type = typeUtils.getTypeAtLocation(parserServices, node);

We'd probably want to export this as a publicly available & documented API, so it's not confusing to consumers why our source code doesn't look like examples.

One downside would be that we're obfuscating how to use TypeScript APIs. I hate to add to complexity of understanding these already hard-to-understand things...

You must be logged in to vote

Replies: 3 comments

Comment options

I would say we could probably go one step further and just offer all of this off of the parser serivces!

For example:

type ParserServices = {
  getTypeAtLocation(node: TSESTree.Node): ReturnType<ts.TypeChecker['getTypeAtLocation']>;
};

const parserServices = util.getParserServices(context);

parserServices.getTypeAtLocation(node);

That would make it even more straight-forward for people to use the tooling!

You must be logged in to vote
0 replies
Comment options

Oh interesting. I like putting this as a member of ParserServices, though I'm hesitant to put potentially dozens of them as siblings of our own properties. Maybe parserServices.checker.getTypeAtLocation?

You must be logged in to vote
0 replies
Comment options

the reason I like it as a direct sibling is it's one less step.
Right now people do things like

const {program} = util.getParserServices(context);
const checker = program.getTypeChecker();

Adding it as a separate property would make it more likely there's a clash if the consumer needs a more advanced API than what we offer.
For example:

const {checker, program} = util.getParserServices(context);
const checker2 = program.getTypeChecker();

If we build it right then most usecases shouldn't really need to ever manually touch program/esTreeNodeToTSNodeMap/tsNodeToESTreeNodeMap!

You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
🤔
RFCs
Labels
repo maintenance things to do with maintenance of the repo, and not with code/docs accepting prs Go ahead, send a pull request that resolves this issue
2 participants
Converted from issue

This discussion was converted from issue #5937 on November 17, 2022 15:54.

Morty Proxy This is a proxified and sanitized view of the page, visit original site.