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 =.

[privatenumber]

For TS, Oxc parser is a possible alternative to es-module-lexer

[SukkaW]

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.

[SukkaW]

guybedford/es-module-lexer#185 is merged and released.

We can try to implement ESM and CJS scan with cjs-module-lexer and es-module-lexer. Currently, there is no good alternative for TypeScript, so TypeScript projects have to fall back to the current AST parsing.

[Samuel-Therrien-Beslogic]

Not so much a "performance improvement" from the plugin. But anyone landing on this issue looking at speeding up their run can consider disabling the namespace rule.

• import/namespace is very slow import-js/eslint-plugin-import#2340

It's not really as useful with TypeScript anyway

Edit: Answer below is what the linked issue is saying as well. I'm not posting it as a fix. It's a (hopefully temporary) workaround with an explanation for users who'd like a linting performance boost by dropping the affected rules. Until a proper solution comes around.

[SukkaW]

Not so much a "performance improvement" from the plugin. But anyone landing on this issue looking at speeding up their run can consider disabling the namespace rule.

• import/namespace is very slow import-js/eslint-plugin-import#2340

It's not really as useful with TypeScript anyway

Disabling import/namespace just won't help. Any rule can initiate external module parsing, and after parsing the AST will be cached (so the other rules can benefit from this).

It just so happens that import/namespace initiates most external modules to be parsed. If you disable the import/namespace rule, other rules will initiate their parsing tasks and become slower. The total lint time won't reduce by much.

The only escape is what I am proposing here, replacing external module parsing with external module lexing completely.

[JounQin]

@SukkaW https://github.com/joomcode/parse-imports-exports supports TypeScript out of box, I found it at gajus/eslint-plugin-jsdoc#1372.