@types for espree?

[srijan-paul]

Currently I do not see any way of using the espree npm package in a typescript project.
I think the API is simple enough that .d.ts files can be provided with some effort.

I'm curious if such declarations already exist.
If not, I'd be more than happy to contribute them myself.

[nzakas]

While Espree itself has a fairly simple API, the AST that is returned is quite involved. Would it be necessary to get type definitions for all of the AST nodes too?

[srijan-paul]

Would it be necessary to get type definitions for all of the AST nodes too?

I believe so, yeah.
That way working with the AST in typescript becomes convenient, like with typescript-eslint-parser's AST.
What do you think?

[nzakas]

I think it's a good idea, but my concern is always about maintainability. I don't think checking in a separate .d.ts file that we have to manually update is a good idea. If we can make it automatic, then I think it's worth pursuing. I've done some experimenting with tsc and JSDoc that can probably handle the Espree-specific stuff:
https://humanwhocodes.com/snippets/2020/10/create-typescript-declarations-from-javascript-jsdoc/

It looks like there's a DefinitelyTyped file for ESTree, which should cover the AST bit:
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/estree/index.d.ts

If you're interesting in investigating this, we can definitely consider it.

[srijan-paul]

If we can make it automatic, then I think it's worth pursuing

Yeah, I don't think it's that common to write .d.ts files by hand - except for some cases where people tend to simulate dependent types (to some limited extent). I think it would be great if we could have them laid out such that the properties of a node can be inferred if the type is known. For example:

function foo(node: Node) {
  if (node.type === 'CallExpression') {
     // Accessing the property `callee` without casting `node` to the `CallExpression` type should not throw
     // a typescript compiler error.
    console.log(node.callee);
  }
}

As for the API, I think JSDoc should take care of it.
What do you think?

[nzakas]

I think if we can make all of this automatic, then we can include it in the Espree package during each release so folks don't have to go through the trouble of downloading a separate package. :)

I think it would be great if we could have them laid out such that the properties of a node can be inferred if the type is known.

If there's an easy way to do that without manual intervention, that sounds like a bonus.

It sounds like you have a good idea of how this could work, so if you want to prototype something up for feedback, we can go from there.

Thanks!

[srijan-paul]

It sounds like you have a good idea of how this could work, so if you want to prototype something up for feedback, we can go from there.

Yep, I'll open a PR in about a week or so and lets see if it works out.

[nzakas]

Awesome, thank you!

[srijan-paul]

#530 should help with TS bindings for parts of the API.

[brettz9]

It looks like there's a DefinitelyTyped file for ESTree, which should cover the AST bit: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/estree/index.d.ts

@nzakas : Do you think that eslint-visitor-keys should, in place of manually maintaining its own listing, parse this @types/estree AST (as with @typescript-eslint/parser), from which espree derives (more clearly so after #532 ) and build its own listing therefrom, allowing for more automated updates to that package (especially as it looks like that declaration file is the best thing as far as a formal technical authority given the apparent lack of interest in ESTree itself handling it per estree/estree#256 (comment) )?

[nzakas]

That is a fascinating idea. anything we can do to automate types sounds good to me.

[brettz9]

Ok, great--I can look into adding that.