Ideas about how to significantly improve performance

[SukkaW]

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). Then eslint-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 like es-module-lexer or cjs-module-lexer to scan the imports/exports we skip the entire parsing-into-AST process and significantly improve performance for a few rules.

[SukkaW]

We have es-module-lexer that works for ESM and cjs-module-lexer for CommonJS. But we still need lexers for JSX / TypeScript / TSX (or even flow). I still want TypeScript to benefit from this.

Oxc says they will have one for ESM and TypeScript/TSX, but they won't support the CJS.

And we also have rs-module-lexer @fz6m.

[silverwind]

We have es-module-lexer that works for ESM and cjs-module-lexer for CommonJS. But we still need lexers for JSX / TypeScript / TSX (or even flow). I still want TypeScript to benefit from this.

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.

[SukkaW]

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.

But IMHO it might not work with export =.