fix(es/module): preserve ./ prefix for hidden directory imports #11489
Conversation
When resolving imports with `baseUrl`, hidden directories (dot-prefixed like `.foo`) were incorrectly losing their `./` prefix, turning `./.foo` into `.foo` which is not a valid relative import.
The issue was that the code checked `starts_with('.')` to determine if a path was already relative, but this matched hidden directory names (which start with `.`) even though they need a `./` prefix to be valid relative paths.
The fix changes the check to look for actual relative path markers (`./` or `../`) instead of just `.`.
Fixes #9551
Co-authored-by: Donny/강동윤 <kdy1@users.noreply.github.com>
|
|
|
Binary Sizes
Commit: d43031b |
Merging this PR will not alter performance
Comparing 
Footnotes
|
|
@claude Fix CI |
|
Claude finished @kdy1's task in 2m 39s —— View job Fixing CI
Root Cause: Solution: Commit: 087a721 - CI is now running. |
…e imports The previous fix checked for Unix-style relative path prefixes (./ and ../) but on Windows, diff_paths returns paths with backslashes. This caused the code to incorrectly add ./ prefix to paths like ..\url-alphabet\index.js, resulting in ./..\url-alphabet\index.js instead of ..\url-alphabet\index.js. Fixes CI failures on Windows. Co-authored-by: Donny/강동윤 <kdy1@users.noreply.github.com>
When resolving imports with
baseUrl, hidden directories (dot-prefixed like.foo) were incorrectly losing their./prefix, turning./.foointo.foowhich is not a valid relative import.The issue was that the code checked
starts_with('.')to determine if a path was already relative, but this matched hidden directory names (which start with.) even though they need a./prefix to be valid relative paths.The fix changes the check to look for actual relative path markers (
./or../) instead of just..Fixes #9551
Generated with Claude Code