Does not support TypeScript specific syntaxes

[JounQin]

import { parseImportsExports } from "parse-imports-exports";

const importsExports = parseImportsExports(`
import x = require('x')

export = 1
`);

console.log(importsExports);

{
  namedImports: undefined,
  namespaceImports: undefined,
  dynamicImports: undefined,
  requires: [Object: null prototype] { x: [ [Object] ] },
  typeNamedImports: undefined,
  typeNamespaceImports: undefined,
  typeDynamicImports: undefined,
  namedReexports: undefined,
  namespaceReexports: undefined,
  starReexports: undefined,
  typeNamedReexports: undefined,
  typeNamespaceReexports: undefined,
  typeStarReexports: undefined,
  defaultExport: undefined,
  namedExports: undefined,
  declarationExports: undefined,
  typeNamedExports: undefined,
  typeExports: undefined,
  interfaceExports: undefined,
  namespaceExports: undefined,
  commonJsNamespaceExport: undefined,
  commonJsExports: undefined,
  errors: [Object: null prototype] {
    '2:1': 'Cannot find end of `import` statement:\nimport ',
    '4:1': 'Cannot parse declaration identifier of `export ...` statement:\n' +
      'export = 1'
  },
  [Symbol(parse-imports-exports:context-key)]: undefined
}

[uid11]

Thanks for the issue! You're absolutely right — parse-imports-exports currently does not support TypeScript-specific syntax like export = and import = require().

Thanks also for including a clear and minimal reproduction — that made it very easy to understand the problem.

Originally, I didn't plan to support this syntax, as I thought it was no longer encouraged by the TypeScript team and is only used in CommonJS modules.

However, since you've run into a need for it, I do plan to add support for it.
There's no technical blocker — it just requires a bit of time to implement properly.

Thanks again for reporting this!

[JounQin]

@uid11

Thanks! We want to adopt this awesome library into un-ts/eslint-plugin-import-x#201 (comment), hope we can make them better together! ❤️

Before landing the integration, we'd want to make sure it'd would work expectedly by enabling test cases from https://github.com/nodejs/cjs-module-lexer and https://github.com/guybedford/es-module-lexer, I and @SukkaW would raise PRs for them, WDYT?

Additionally, I want to ask would supporting Flow would be difficult, AFAIK there is only import typeof/export typeof syntax which is different with TypeScript for imports/exports. If you agree, we can also try to raise PRs for it.

[uid11]

Thanks, I now understand your context and your original problem better.

First, I will add support for export = and import = require() anyway, for the sake of full TypeScript support.

As for cjs-module-lexer and es-module-lexer, and the tests from them — things are much more complicated here.
These serious lexers support parsing very complex expressions with imports and exports, as I can see from the tests in https://github.com/nodejs/cjs-module-lexer/blob/main/test/_unit.js and in https://github.com/guybedford/es-module-lexer/blob/main/test/_unit.cjs.
In particular, they support token separation by any whitespace characters, according to the ECMAScript standard, comments between any tokens according to the ECMAScript standard, as well as complex heuristics for CommonJS (for the result of different bundlers), such as Object.defineProperty(exports, ...), module.exports = {...a, ...b, ...require('dep1')}, and so on.
These universal lexers aim to extract import/export statements from any syntactically valid JS code — essentially, they are full lexers that only care about imports and exports.

In contrast, parse-imports-exports is much simpler and smaller — it is intended to support only well-formatted code (for example, with Prettier or Biome).
It does not support extra whitespace (or lack thereof) where it is actually allowed (only in some places), does not support multiline comments where they are standardly allowed (only in some places), does not support complex heuristics for the module.exports object. parse-imports-exports also only parses import and export declarations that start on a newline.

Because of this, parse-imports-exports will fail most of the tests in cjs-module-lexer and es-module-lexer.

parse-imports-exports is designed to work on most of standart codebases, but 100% ECMAScript syntax support is almost impossible in it (it would make parsing difficult and slow).
We can fine-tune the parsing of individual expressions (say, adding support for any whitespace or multiline comments between certain tokens), but only up to a certain level.

So you first need to understand whether parsing with such restrictions is suitable for a widely used tool like eslint-plugin-import-x.
We can discuss this in more detail with specific examples.

As for Flow support — in the Flow docs I only see import typeof expressions, which are not in TypeScript, and it is very easy to add support for them (literally here), since they are otherwise equivalent to import type.
I will add support for them along with export = and import = require().
I don't seem to see expressions like export typeof ... in the documentation.

[uid11]

As for pull requests in general — of course, I'm all for it.

I'm also happy to help you with this integration. We just need to understand what requirements are set for such a parser in your tool, and how realistic it is to meet them in parse-imports-exports.
For example, we can list tests from cjs-module-lexer/es-module-lexer that should pass.

[JounQin]

@uid11

Great thanks again for the investigation deeply!

We'll try to make a prototype based on parse-imports-exports after the original issue and flow is resolved, and observe how many test cases would fail, and also the original full parse concept would be dropped, just could be a fallback when parser-imports-exports fails.