Skip to content
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

SWC transform with baseUrl mangles imports of hidden directories #9551

Open
askoufis opened this issue Sep 12, 2024 · 0 comments
Open

SWC transform with baseUrl mangles imports of hidden directories #9551

askoufis opened this issue Sep 12, 2024 · 0 comments
Assignees
Labels
Milestone

Comments

@askoufis
Copy link

askoufis commented Sep 12, 2024

Describe the bug

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:

// input

export { dotFoo } from "./.foo";
export { dotFoo as dotFooReExport } from "src/.foo";
export { foo } from "./foo";
export { foo as fooReExport } from "src/foo";
export { notReal } from "./.notReal";
export { fooFoo } from "./foo.foo";

// output when `baseUrl` is not provided

export { dotFoo } from "./.foo";
export { dotFoo as dotFooReExport } from "src/.foo"; // obviously doesn't resolve, but at least is unchanged
export { foo } from "./foo";
export { foo as fooReExport } from "src/foo";
export { notReal } from "./.notReal";
export { fooFoo } from "./foo.foo";

// unexpected output when `baseUrl` is provided

export { dotFoo } from ".foo"; // incorrect, should be ./.foo
export { dotFoo as dotFooReExport } from ".foo"; // incorrect, should be ./.foo
export { foo } from "./foo";
export { foo as fooReExport } from "./foo"; // correct for non-hidden directory
export { notReal } from "./.notReal"; // import of a hidden directory that is not on disk is unchanged
export { 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)

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

Binaries:
    Node: 20.17.0
    npm: 10.8.2
    Yarn: N/A
    pnpm: 9.10.0

Relevant Packages:
    @swc/core: 1.7.26
    @swc/helpers: N/A
    @swc/types: N/A


SWC Config:
    output: N/A
    .swcrc path: N/A

Next.js info:
    output: N/A

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 the src/.foo import path to be converted to ./.foo.

Actual behavior

No response

Version

1.7.26

Additional context

No response

@askoufis askoufis added the C-bug label Sep 12, 2024
@kdy1 kdy1 added this to the Planned milestone Sep 12, 2024
@kdy1 kdy1 self-assigned this Sep 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants