Don't use parser for Node v22?

[timfish]

Testing on top of PR #85, I found that for Node v22, the parser doesn't appear to be required and we can revert back to the faster path of import(srcUrl).then(Object.keys).

We would need the parser to support v18.19 -> v21.

We could reduce the potential bundle size caused by the parser (~100KB) by:

• Moving the parser to it's own package (eg. 'import-in-the-middle-parser')
• Set package.json#engines to the Node versions where it's required
• Make it an optionalDependency of import-in-the-middle
• import('import-in-the-middle-parser') in hook.js in a try/catch

When installed with Node versions requiring the parser, the optional dependency will be installed and used.
When installed with Node v22+, the optional dependency will be missing and will not be included in any bundle

[mohd-akram]

From my testing, the parser is only required for NODE_MAJOR == 20 && NODE_MINOR < 6. However, it's not possible to use libraries with circular dependencies (like openai) without the parser. That's why it fails below 18.19 and 20 (the threshold used to activate the parser). We seem to expect circular dependencies to fail based on v14-assert-cyclical-dependency-failure.mjs (even though regular Node.js import succeeds) so maybe this isn't a problem. Note that it fails with a code 13 error and there's some explanation for that in nodejs/node#44601.

[timfish]

Regular Node.js import can handle cyclic dependencies but dynamic import cannot.

Yeah it really is only the openai test that fails and needs the parser.

It's strange that the same test now passes in v22. I can't find anything in the release notes that would suggest this limitation has been removed.

[mohd-akram]

Regular Node.js import can handle cyclic dependencies but dynamic import cannot.

That doesn't seem to be strictly true. Adding const openai = await import('openai') runs fine in regular Node.js. The problem seems to happen if you do that inside the cycle, which I guess because import-in-the-middle is acting as a loader, that counts.

It's strange that the same test now passes in v22.

It's failing but with a 0 exit code :) If you add a console.log after the import it doesn't reach there.

[timfish]

It's failing but with a 0 exit code :) If you add a console.log after the import it doesn't reach there.

Ah that's a shame, I missed that entirely and only noticed the tests all passing 😭

The problem seems to happen if you do that inside the cycle, which I guess because import-in-the-middle is acting as a loader, that counts.

That means we could potentially perform await import('lib') in a worker that isn't using the import-in-the-middle loader to get the exports but I guess the performance would suck. In some quick testing, the parser looks quicker than import() anyway in Node v22. I guess it's only parsing and Node is evaluating on top of that 🤷‍♂️