Open fire332 opened 9 months ago
cc @Brooooooklyn
I've narrowed the issue down.
compile
function here checks to see if filename
is contained in options.files
to determine whether to transpile but that will always be true as the string passed by Node.JS to filename
starts with file:///
while the string it checks against doesn't.
This issue isn't present without tsconfig.json
because options.files
is not set when tsconfig.json
is not present.
The string passed to the filename
parameter of the compile
function here starts with file:///
. When a tsconfig
is parsed, files
is attached to options
argument of compile
here. When the files
property is present, compile
will check to see if filename
is contained in files
. However, on the PLATFORM === 'win32'
branch, filename !== resolve(process.cwd(), file)
will always be true as the right hand side of the conditional expression does not start with file:///
while the left hand side does. That means files will never be transpiled.
On a second note, the check on Windows will never work anyways because path.resolve
converts the separators to the Windows version while filename
uses POSIX-style separators. Maybe instead of filename !== resolve(process.cwd(), file)
, use !normalize(filename).endsWith(resolve(process.cwd(), file))
.
Related: https://github.com/swc-project/swc-node/issues/710#issuecomment-1755713552
I've mentioned in my comment here, to fix the issue the protocol can be removed using fileUrlToPath
Describe the bug
I cannot reproduce this with the playground or CLI, only with
@swc-node/register
This issue ONLY occurs when a
tsconfig.json
is present. Even if it is completely blank (0 bytes; not even{}
). Same issue occurs with recommendedtsconfig.json
compilerOptions
. Iftsconfig.json
is deleted, this issue doesn't occur.Steps to reproduce
pnpm init
pnpm add -D @swc-node/register
./index.ts
.touch tsconfig.json
node --import @swc-node/register/esm-register ./index.ts
Input code
Config
Playground link (or link to the minimal reproduction)
https://play.swc.rs/?version=1.4.0&code=H4sIAAAAAAAAAz2OzQrCMBCE74W8w9yqr2ART97Ed4jrtgbyx24OQum7a5roZZaZD3bGhZykgN9ZWBWzpICxu3Eyg2v8xT5w6biZSs3wZPJWGItPD%2BuxmgGINrBmS4xrf7vHgIuFZa7glsj6fw6Q5nuKxJcTtIiLy9TIVs9XttpFKWqBzRnn3%2BDDcV%2FxAXF5lWHGAAAA&config=H4sIAAAAAAAAA1VPOw7DIAzdOQXy3KFi6NA79BCIOhERAYQdqSjK3QsJpM1mv4%2Ff8yqkhIkMPOVaxrJEnQjTuReEsmf9KQhwjkgm2chw6yxTpQbtCHdoOxhgnUbk6kJSd6WaA1wIhN3RsNl6O%2BT%2FTBPmmJDoKqxS7UeH10TRUmEO72Un2y%2B179HgAT9RDzsPg6VXd3JaUGxfBMLf3xcBAAA%3D
SWC Info output
Above output seems broken. pnpm --version: 18.15.2
Expected behavior
Node shouldn't throw a syntax error.
Actual behavior
No response
Version
See above.
Additional context
No response