You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When transform is given a baseUrl, relative and base-relative import paths of hidden (dot-prefixed) directories become mangled. The examples in the reproduction that are incorrect are ./.foo becoming .foo, and src/.foo become .foo. Below is the output I get when running pnpm run bug in the reproduction repo, with some extra comments:
// inputexport{dotFoo}from"./.foo";export{dotFooasdotFooReExport}from"src/.foo";export{foo}from"./foo";export{fooasfooReExport}from"src/foo";export{notReal}from"./.notReal";export{fooFoo}from"./foo.foo";// output when `baseUrl` is not providedexport{dotFoo}from"./.foo";export{dotFooasdotFooReExport}from"src/.foo";// obviously doesn't resolve, but at least is unchangedexport{foo}from"./foo";export{fooasfooReExport}from"src/foo";export{notReal}from"./.notReal";export{fooFoo}from"./foo.foo";// unexpected output when `baseUrl` is providedexport{dotFoo}from".foo";// incorrect, should be ./.fooexport{dotFooasdotFooReExport}from".foo";// incorrect, should be ./.fooexport{foo}from"./foo";export{fooasfooReExport}from"./foo";// correct for non-hidden directoryexport{notReal}from"./.notReal";// import of a hidden directory that is not on disk is unchangedexport{fooFoo}from"./foo.foo";
Obviously .foo cannot be resolved from the src/index.js file. Unless I'm misunderstading how baseUrl works, this seems incorrect to me.
I was unable to reproduce this inside the SWC playground as the bug depends on there being a filesystem. I suppose there's some resolution going on inside SWC when baseUrl is provided. Deleting the .foo directory results in neither of the imports to the .foo directory being altered, regardless of whether or not baseUrl is provided. This is still the case for a regular directory like foo though, so I suppose this behaviour is at least consistent between hidden and non-hidden directories.
Input code
No response
Config
No response
Playground link (or link to the minimal reproduction)
Imports to hidden (dot-prefixed) directories should not be mangled when a baseUrl is present. In the reproduction I would expect the ./.foo import path to be unchanged, and the src/.foo import path to be converted to ./.foo.
Actual behavior
No response
Version
1.7.26
Additional context
No response
The text was updated successfully, but these errors were encountered:
Describe the bug
When
transform
is given abaseUrl
, relative and base-relative import paths of hidden (dot-prefixed) directories become mangled. The examples in the reproduction that are incorrect are./.foo
becoming.foo
, andsrc/.foo
become.foo
. Below is the output I get when runningpnpm run bug
in the reproduction repo, with some extra comments:Obviously
.foo
cannot be resolved from thesrc/index.js
file. Unless I'm misunderstading howbaseUrl
works, this seems incorrect to me.I was unable to reproduce this inside the SWC playground as the bug depends on there being a filesystem. I suppose there's some resolution going on inside SWC when
baseUrl
is provided. Deleting the.foo
directory results in neither of the imports to the.foo
directory being altered, regardless of whether or notbaseUrl
is provided. This is still the case for a regular directory likefoo
though, so I suppose this behaviour is at least consistent between hidden and non-hidden directories.Input code
No response
Config
No response
Playground link (or link to the minimal reproduction)
https://github.com/askoufis/swc-baseurl-bug
SWC Info output
Operating System:
Platform: darwin
Arch: arm64
Machine Type: arm64
Version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6000
CPU: (10 cores)
Models: Apple M1 Pro
Expected behavior
Imports to hidden (dot-prefixed) directories should not be mangled when a
baseUrl
is present. In the reproduction I would expect the./.foo
import path to be unchanged, and thesrc/.foo
import path to be converted to./.foo
.Actual behavior
No response
Version
1.7.26
Additional context
No response
The text was updated successfully, but these errors were encountered: