-
-
Notifications
You must be signed in to change notification settings - Fork 24
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
Ideas about how to significantly improve performance #201
Comments
We have Oxc says they will have one for ESM and TypeScript/TSX, but they won't support the CJS. And we also have |
For Typescript could strip types with https://github.com/nodejs/amaro or the underlying https://swc.rs/docs/references/wasm-typescript and then pass the result to the lexers. Would be interesting to hear about the performance of that approach vs. full AST parsing. |
But IMHO it might not work with |
For TS, Oxc parser is a possible alternative to es-module-lexer |
Not supported, yet: oxc-project/oxc#2608 (comment) I have already raised this to the oxc team. |
guybedford/es-module-lexer#185 is merged and released. We can try to implement ESM and CJS scan with |
Currently, when
eslint-plugin-import-x
finds an import, it will resolve the real path of the module (through the eslint import resolvers), read the file, and then parse the module into the AST using the configured parsers (import-x/parser
) or the default parser (ruleContext.parserPath
). Theneslint-plugin-import-x
tried to extract all exports/imports by walking through AST.Parse any referenced modules are very heavy tasks, resulting
eslint-plugin-import-x
being slow. But if we use something likees-module-lexer
orcjs-module-lexer
to scan the imports/exports we skip the entire parsing-into-AST process and significantly improve performance for a few rules.The text was updated successfully, but these errors were encountered: