feat: merge from upstream oxc-project/oxc-resolver - 4th
#86
Conversation
Fixes #454 This PR changed the name and return type of `strip_windows_prefix` to `try_strip_windows_prefix`, allowing it to return `None` to indicate unsupported [DOS device paths](https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats#dos-device-paths). Most significantly, symlinks referring to a drive without drive letter, usually accessed via a mount point (Mounted Volume), should not be resolved at all, as nodejs `import`/`require` does not support such properly, as of Node 22. This PR also rectified the [UNC path](https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats#unc-paths) resolution to prepend the `"\\"` portion to the path. --------- Co-authored-by: Boshen <[email protected]>
## 🤖 New release
* `oxc_resolver`: 5.3.0 -> 6.0.0 (⚠ API breaking changes)
### ⚠ `oxc_resolver` breaking changes
```text
--- failure inherent_method_missing: pub method removed or renamed ---
Description:
A publicly-visible method or associated fn is no longer available under its prior name. It may have been renamed or removed entirely.
ref: https://doc.rust-lang.org/cargo/reference/semver.html#item-remove
impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.40.0/src/lints/inherent_method_missing.ron
Failed in:
FileSystemOs::strip_windows_prefix, previously in file /tmp/.tmpZFrfKd/oxc_resolver/src/file_system.rs:168
```
<details><summary><i><b>Changelog</b></i></summary><p>
<blockquote>
##
[6.0.0](oxc-project/oxc-resolver@oxc_resolver-v5.3.0...oxc_resolver-v6.0.0)
- 2025-04-22
### <!-- 1 -->Bug Fixes
- properly handle DOS device paths in strip_windows_prefix
([#455](oxc-project/oxc-resolver#455))
</blockquote>
</p></details>
---
This PR was generated with
[release-plz](https://github.com/release-plz/release-plz/).
WalkthroughThe changes introduce updates across configuration files, dependency versions, and core logic for handling Windows-specific path normalization. A new function, Changes
Sequence Diagram(s)sequenceDiagram
participant Caller
participant FileSystem
participant WindowsModule
participant Error
Caller->>FileSystem: read_link(path)
FileSystem->>WindowsModule: try_strip_windows_prefix(path)
WindowsModule-->>FileSystem: PathBuf or ResolveError::PathNotSupported
FileSystem-->>Caller: PathBuf or Error
Poem
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Pull Request Overview
This PR merges upstream changes from oxc-project/oxc-resolver and updates Windows path handling. The key changes include:
- Updating tests to reflect changes in the Resolution API and module path construction.
- Introducing a new Windows-specific module to safely handle DOS device paths.
- Adjusting file system functions to leverage the new Windows prefix stripping logic.
Reviewed Changes
Copilot reviewed 8 out of 12 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| tests/resolve_test.rs | Updated imports and test expectations for module resolution with new API. |
| src/windows.rs | New module to convert DOS device paths to standard paths using unsafe blocks. |
| src/lib.rs | Added conditional compilation for the Windows module. |
| src/fs_cache.rs | Modified Windows path handling to call the new try_strip_windows_prefix. |
| src/file_system.rs | Updated Windows branch to use try_strip_windows_prefix with pattern matching. |
| src/error.rs | Added a new error variant for unsupported Windows paths. |
| pnpm-workspace.yaml | Configured virtualStoreDirMaxLength to support long Windows paths. |
| CHANGELOG.md | Documented the bug fix for DOS device path handling. |
Files not reviewed (4)
- fixtures/pnpm-workspace/packages/lib/package.json: Language not supported
- npm/package.json: Language not supported
- package.json: Language not supported
- pnpm-lock.yaml: Language not supported
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #86 +/- ##
==========================================
+ Coverage 93.24% 93.67% +0.42%
==========================================
Files 13 13
Lines 2858 2844 -14
==========================================
- Hits 2665 2664 -1
+ Misses 193 180 -13 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
CodSpeed Performance ReportMerging #86 will not alter performanceComparing Summary
|
There was a problem hiding this comment.
Caution
Changes requested ❌
Reviewed everything up to ed82ebd in 2 minutes and 28 seconds. Click for details.
- Reviewed
313lines of code in11files - Skipped
1files when reviewing. - Skipped posting
11draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. tests/resolve_test.rs:49
- Draft comment:
Ensure consistency in mapping resolutions. Some tests useResolution::into_path_bufdirectly and others viaunrs_resolver::Resolution::into_path_buf. This is fine if intentional, but consider unifying for clarity. - Reason this comment was not posted:
Confidence changes required:30%<= threshold50%None
2. tests/resolve_test.rs:217
- Draft comment:
The Windows symlinked long filename test asserts that the resolved path is super long (>260 characters). This is good for Windows-specific behavior, but adding comments on why the test is needed could aid future maintainers. - Reason this comment was not posted:
Confidence changes required:20%<= threshold50%None
3. src/windows.rs:23
- Draft comment:
Risky index access: the code assumes thatphas at least 2 bytes when checkingp[1] != b':'. Consider adding a length check onpbefore indexing to avoid potential panic. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% The code is handling Windows paths, specifically after stripping "\?" or "\." prefixes. For a valid DOS path, there must be a drive letter followed by a colon (e.g., "C:"). The strip_prefix() operation guarantees that p only matches if the prefix exists. Given the strict Windows path format requirements, it's extremely unlikely that a valid Windows path would ever be shorter than 2 characters after these prefixes. I could be wrong about the guarantees of Windows path formats - there might be edge cases I'm not considering. The suggestion to add a length check is defensive programming and wouldn't hurt. While defensive programming is good practice, in this case we're dealing with a very specific Windows path format where the structure is well-defined. The test cases cover the main scenarios. While the comment suggests a valid defensive programming practice, the risk is extremely low given the well-defined Windows path format requirements. The current code is reasonable.
4. src/windows.rs:12
- Draft comment:
The usage of unsafe conversions viafrom_encoded_bytes_uncheckedrequires strong guarantees that the OS string bytes are valid. Consider adding or referencing tests/documentation verifying these preconditions. - Reason this comment was not posted:
Comment looked like it was already resolved.
5. pnpm-workspace.yaml:10
- Draft comment:
The addition ofvirtualStoreDirMaxLength: 1024is clear, but ensure that this value fits all environments and document its purpose if not already. - Reason this comment was not posted:
Confidence changes required:20%<= threshold50%None
6. tests/resolve_test.rs:217
- Draft comment:
The Windows long filename test uses a path length assertion. Confirm that this test runs only on Windows (or is conditionally skipped) to avoid false failures on other OSes. - Reason this comment was not posted:
Confidence changes required:30%<= threshold50%None
7. CHANGELOG.md:62
- Draft comment:
Typographical error: In the [1.4.0] release section, 'pacakge.json' is misspelled. Please correct it to 'package.json'. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
8. src/error.rs:29
- Draft comment:
Typo: The comment on the MatchedAliasNotFound variant reads "Matched alias value not found" with two spaces between 'value' and 'not'. Could you remove the extra space for consistency? - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
9. src/error.rs:37
- Draft comment:
Typo: In the comment for TsconfigSelfReference, "points to it self" should be written as "points to itself". - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
10. src/error.rs:76
- Draft comment:
Typo/Error: In the error message for the Restriction variant, the formatting string is "Path "{0}" restricted by {0}". Given that the variant takes two PathBuf arguments, it seems the second placeholder should be {1} instead of repeating {0}. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
11. tests/resolve_test.rs:49
- Draft comment:
The test uses an inconsistent reference toResolution: in some places it is referred to directly (e.g.Resolution::into_path_buf), while in others it is prefixed withunrs_resolver::(e.g.unrs_resolver::Resolution::into_path_buf). SinceResolutionis already imported at the top of the file, it would be clearer to use it consistently. Consider updating the occurrences ofunrs_resolver::Resolution::into_path_bufto simplyResolution::into_path_buf. - Reason this comment was not posted:
Comment was on unchanged code.
Workflow ID: wflow_i25T5Q36L3GNtk88
You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/file_system.rs (1)
196-196: Consider better handling of "unreachable" error cases.Using
unreachable!()assumes that no other error types besidesPathNotSupportedwill ever be returned. This could cause a panic if the assumption is violated in the future.Consider handling all possible error cases explicitly or propagating the error instead:
- match crate::windows::try_strip_windows_prefix(path) { - // We won't follow the link if we cannot represent its target properly. - Ok(p) | Err(crate::ResolveError::PathNotSupported(p)) => Ok(p), - _ => unreachable!(), - } + match crate::windows::try_strip_windows_prefix(path) { + // We won't follow the link if we cannot represent its target properly. + Ok(p) | Err(crate::ResolveError::PathNotSupported(p)) => Ok(p), + Err(e) => { + tracing::warn!("Unexpected error stripping Windows path prefix: {:?}", e); + // Fall back to the original path + Ok(path) + } + }src/windows.rs (1)
8-39: Well-structured implementation for Windows path normalization.This function correctly handles various Windows DOS device path formats and converts them to standard paths that can be consumed by Node.js import/require syntax. The error handling for unsupported path formats is appropriate.
Consider adding a check to ensure
phas at least 2 bytes before accessingp[1]on line 24, although it's unlikely to be an issue given the context:// Assuming traditional DOS path "\\?\C:\" -if p[1] != b':' { +if p.len() < 2 || p[1] != b':' { // E.g., // \\?\Volume{b75e2c83-0000-0000-0000-602f00000000} // \\?\BootPartition\
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (11)
CHANGELOG.md(1 hunks)fixtures/pnpm-workspace/packages/lib/package.json(1 hunks)npm/package.json(1 hunks)package.json(1 hunks)pnpm-workspace.yaml(1 hunks)src/error.rs(1 hunks)src/file_system.rs(1 hunks)src/fs_cache.rs(1 hunks)src/lib.rs(1 hunks)src/windows.rs(1 hunks)tests/resolve_test.rs(4 hunks)
🔇 Additional comments (15)
npm/package.json (1)
51-51: Dependency version update looks good.Upgrading napi-postinstall from ^0.1.1 to ^0.1.5 aligns with the broader improvements in handling Windows path prefixes in this PR.
src/error.rs (1)
44-46: Well-structured error handling for unsupported paths.The new error variant with descriptive documentation and error message provides proper handling for unsupported path constructs like Windows UNC paths with Volume GUIDs. This complements the Windows path handling improvements introduced in this PR.
pnpm-workspace.yaml (1)
10-11: Good configuration for long path testing.The addition of
virtualStoreDirMaxLengthwith a clear explanatory comment is helpful for supporting the Windows symlinked long filename tests. The value of 1024 provides sufficient length for these test cases.fixtures/pnpm-workspace/packages/lib/package.json (1)
7-7: React dependency update looks good.Simple version update from ^19.0.0 to ^19.1.0 as part of general maintenance across the workspace.
package.json (1)
24-24: LGTM! Clean dependency update to latest vitest version.This minor version update to vitest from 3.1.1 to 3.1.2 will help support the Windows path handling changes introduced in this PR.
CHANGELOG.md (1)
9-11: Well-documented changelog entry.The changelog entry appropriately documents the bug fix for DOS device path handling and includes a reference to the upstream PR.
src/lib.rs (1)
68-69: Good use of conditional compilation for platform-specific code.Adding a dedicated Windows module that's only compiled on Windows targets is a clean way to organize platform-specific functionality. This centralizes the Windows path handling logic in one place, improving maintainability.
src/file_system.rs (1)
192-197: Improved Windows path handling with better error management.The updated code now uses the centralized
try_strip_windows_prefixfunction from the Windows module, which returns a properResulttype, allowing for better error handling of unsupported path formats.src/fs_cache.rs (1)
82-86: The Windows path handling improvement looks solid.The change from
#[cfg(windows)]to#[cfg(target_os = "windows")]is more precise, specifically targeting Windows OS rather than the Windows platform family. The new approach usingtry_strip_windows_prefixhandles errors properly by returning aResult<PathBuf, ResolveError>instead of transforming the path directly.src/windows.rs (1)
41-64: Good test coverage for Windows path prefix handling.The test cases cover both successful path transformations and error handling for unsupported paths, which is excellent for ensuring reliability.
tests/resolve_test.rs (5)
3-3: Import statement cleanup is a nice improvement.Importing
Resolutiondirectly instead of using fully qualified names makes the code more readable.
24-30: Updated module path structure for styled-components.The path update reflects the current package version and structure, using chained
.join()calls for better readability.
38-38: Improved path construction for CJS resolution.Using
.join()method chain instead of string concatenation improves readability and cross-platform compatibility.
50-50: Improved path construction for ESM resolution.Using
.join()method chain instead of string concatenation improves readability and cross-platform compatibility.
214-236: Well-handled Windows long path test case with enhanced validation.The revised test properly checks long path handling with:
- Detailed comments about pnpm configuration for reproducibility
- An explicit assertion that the path exceeds Windows' 260-character limit
- Cleaner resolution mapping with extracted specifier variable
This test is now expected to pass on Windows thanks to the new path handling implementation.
|
Important
Enhance Windows path handling, update dependencies, and adjust tests for long path support.
try_strip_windows_prefix()insrc/windows.rs.ResolveErrorinsrc/error.rsto includePathNotSupportedfor unsupported paths.reactto^19.1.0infixtures/pnpm-workspace/packages/lib/package.json.napi-postinstallto^0.1.5innpm/package.json.vitestto^3.1.2inpackage.json.try_strip_windows_prefix()insrc/windows.rs.windows_symlinked_longfilenametest intests/resolve_test.rsto handle long paths on Windows.This description was created by
for ed82ebd. You can customize this summary. It will automatically update as commits are pushed.
Summary by CodeRabbit