alexprey / sveltedoc-parser

Generate a JSON documentation for a Svelte (https://github.com/sveltejs/svelte) component
https://www.npmjs.com/package/sveltedoc-parser
MIT License
90 stars 7 forks source link

Investigate typescript integration #49

Closed alexprey closed 2 years ago

alexprey commented 3 years ago

Think about API to able provide functions to handle different integration, the key goal - add support of typescript, the second goal - support of another processors. For example, it can be similar like svelte.preprocess option, that can provide smooth integration with already exists processors.

In ideal case use TS or babel compiler that can provide information about types.

soft-decay commented 3 years ago

After a quick look at some of the typescript compatible parsers (mainly typescript, @babel/parser, and @typescript-eslint/parser) its seems the one that is the closest to the currently used parser (espree) is @typescript-eslint/parser. The node structure and naming seems identical at first glance (other than additional type information), but I have not looked in depth.

The @babel/parser also seems good, but there is a difference in the node types (e.g. I spotted that the node type Literal becomes different nodes such as StringLiteral, BooleanLiteral, etc).

Do you think AST similarities should be a main consideration, or did you have other considerations in mind?

Note: I used https://astexplorer.net/ to compare the AST of different parsers using one of the .svelte file in the project (and adding some types to see the resulting type annotations).

alexprey commented 3 years ago

Using the typescript, and @typescript-eslint/parser is a good at the first look and can reach out key goal. At the same time, @babel/parser is popular and used in different projects and build processes. Also it is flexiable solution, that allow to support different languages in the future.

PS. Thanks for the link to astexplorer, I'll look into that in details

alexprey commented 3 years ago

I'm start to reviewing the libraries provided by @soft-decay. Due this library already used in svelte-intellisense vscode extension, so it should work fast as possible. So, I plan to do performance tests and test library APIs to usability. I hope that I can back with results in few days

alexprey commented 3 years ago

Ok, I'm done with performance measurement with babel-parser, eslint-parser and direct typescript parser. I collect around 2000 source svelte files contained 1758 KB of TS & JS svelte mix.

Parser Error rate Avg. per file (ms) Speed (B/ms)
babel 1.4% 1.418 595.970
eslint 1.4% 4.793 176.288
typescript 0.0% 0.777 1087.253

Based on this results I think that we need to swith to direct typescript compiler to parse source files. But I'm not sure that it can be simple to use.

I plan to introduce this performance testing in CI process, but it need to decide where we should host the test files. The current scope of files I take from github search output by few different quries.

Also, during that I found few issue with parseFileStructureFromContent method. I'll create separate issue for that

binarious commented 2 years ago

Is there any WIP branch or workaround? We'd like to use this library in a TypeScript svelte project.

alexprey commented 2 years ago

Hi @binarious, yes, I have a plan in my mind and some drafts locally. I have the typescript-support branch with TS svelte files for future integration testing and that all for the current moment. I really want to continue work on that library, but don't have enought time on that.

alexprey commented 2 years ago

Ok, keep going with native typescript library.