Closed alexprey closed 2 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).
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
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
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
Is there any WIP branch or workaround? We'd like to use this library in a TypeScript svelte project.
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.
Ok, keep going with native typescript
library.
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.