Both projects are esm-only, with Node v20.14.0, running swc with node --import @swc-node/register/esm-register my-entrypoint.ts. Also they don't have extensions in the internal imports (i.e. import { foo } from './foo' and not import { foo } from './foo.js').
Investigation
In #777 the pattern matching for supported extensions, was fixed. It used to match every single string.
However, now that this pattern is correct, the condition used to check it the specifier was supported was no longer valid for extension-less specifiers.
E.g.
import { foo } from './foo.js';
Is correctly flagged as a supported specifier and processed by swc.
But:
import { foo } from './foo';
Isn't flagged as supported, and then directly passed to the default NodeJS loader, which is unable to undestand it.
Proposed fix
Only apply the early return if the specifier explicitely refers to an unsupported file.
Hello,
I encountered an issue with
@swc-node/register@1.9.2
that did not happen with version1.9.1
Description
Pull requests with the issue:
Both projects are esm-only, with Node v20.14.0, running swc with
node --import @swc-node/register/esm-register my-entrypoint.ts
. Also they don't have extensions in the internal imports (i.e.import { foo } from './foo'
and notimport { foo } from './foo.js'
).Investigation
In #777 the pattern matching for supported extensions, was fixed. It used to match every single string.
However, now that this pattern is correct, the condition used to check it the specifier was supported was no longer valid for extension-less specifiers.
E.g.
Is correctly flagged as a supported specifier and processed by swc.
But:
Isn't flagged as supported, and then directly passed to the default NodeJS loader, which is unable to undestand it.
Proposed fix
Only apply the early return if the specifier explicitely refers to an unsupported file.
WDYT?