-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Imports use absolute paths on windows instead of relative #7806
Comments
Please provide a reproduction |
This is a continuation from this issue: #7603 (comment) A reproduction was asked for. Using this method the issue can be reproduced:
I think the issue should be re-opened as it seems the issue has become much more clear 🙂 |
Hmm.. It seems like a too large app to debug. https://antfu.me/posts/why-reproductions-are-required |
I accept next.js app as repro because I'm familiar with it, but digging into a framework is extremely time consuming |
I see, I understand your time is valuable in that sense. I'll see if I can make simpler repo myself 👍 |
@wp-harm Can you create a smaller repro using nest.js starter kit? I found that https://github.com/KirianCaumes/nestjs-bug-swc-import is small enough |
This comment was marked as outdated.
This comment was marked as outdated.
I think I did you one better. This repo is the root of the issue for NestJS. Essentially I did a deep dive into the NestJS CLI repo and and discovered the line calling the SWC compiler: https://github.com/nestjs/nest-cli/blob/master/lib/compiler/swc/swc-compiler.ts#L165 The method and input to that method I distilled into this repo: https://github.com/harm-less/swc-path-bug. I tested this repo on both my Windows and MacOS system and only the latter worked. The resulting compiled JS is exactly as @martijnimhoff mentioned in his initial message on both operating systems. I did discover a few workarounds during my research, perhaps you can make more sense of them than I can:
I do believe those workaround are not the way to go, so hopefully using are there findings you can more easily discover the root problem @kdy1 💪 |
5c4bfa6 looks like the cause |
So my guess is a difference between UNC and normal path. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Can you try |
@wp-harm Can you try v1.3.80? |
I'm pretty sure this is fixed |
@kdy1 Will do! Tomorrow I'll be back at my Windows system and try it out 👍 |
@kdy1 v1.3.80 didn't fix. |
I updated to v1.3.80 in my minimal reproduction repo, this was the result: "use strict";
Object.defineProperty(exports, "__esModule", {
value: true
});
const _helloworldutils = require("C:/projects/github/typescript-swc-starter/swc-path-bug/src/utils/hello-world.utils.js");
console.log((0, _helloworldutils.helloWorld)());
//# sourceMappingURL=index.js.map The output is still absolute and still references the The same happened to my NestJS app too. |
Same problem here too, I'm using |
Okay, it's not reproducible usnig the Rust testing system of SWC. So my guess is related to |
The repro works if I give |
YES, |
So, should the user manually set the prefix? 😗 |
No, I'll normalize it from the Rust code. It's not matter of prefix, but it's UNC path of Windows |
Using NestJSAfter updating My current setup:tsconfig.json{
"compilerOptions": {
...
"outDir": "./dist",
"baseUrl": ".",
"paths": {
"@common/*": ["src/common/*"],
"@config/*": ["src/config/*"],
"@modules/*": ["src/modules/*"]
}
...
}
}
.swcrc{
"$schema": "https://json.schemastore.org/swcrc",
"sourceMaps": true,
"minify": false,
"jsc": {
...
"baseUrl": "./",
"paths": {
"@common/*": ["src/common/*"],
"@config/*": ["src/config/*"],
"@modules/*": ["src/modules/*"]
},
...
}
} nest-cli-.json{
"$schema": "https://json.schemastore.org/nest-cli",
"collection": "@nestjs/schematics",
"sourceRoot": "src",
"compilerOptions": {
"deleteOutDir": true,
"builder": "swc",
"typeCheck": true
}
} |
That is actually pretty weird. "@nestjs/common": "^10.0.0",
"@nestjs/core": "^10.0.0",
...
"@nestjs/cli": "^10.0.0",
"@nestjs/schematics": "^10.0.0",
"@swc/cli": "^0.1.62",
"@swc/core": "^1.3.83", And the only time when the project starts is when the paths are specified in both "paths": {
"@common/*": ["src/common/*"],
"@config/*": ["src/config/*"],
"@modules/*": ["src/modules/*"]
}, Without specifying these, I'm getting errors: |
In my case VS-Code was automatically importing paths like so "paths": {
"src/*": ["src/*"]
} |
This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Describe the bug
I'm using @swc/core on version 1.3.76. On version 1.3.74, i do not have this problem. I'm also on windows.
When I compile my TS into JS, my imports break because in the output an absolute path is used. This path leads to the uncompiled TS files. Please have a look at the expected vs actual behavior.
Input code
No response
Config
Playground link
No response
Expected behavior
I'm expecting this output:
Actual behavior
I'm getting this output:
Version
1.3.76
Additional context
On 1.3.74 I'm getting the expected behavior.
The text was updated successfully, but these errors were encountered: