This is what I put together from the stackoverflow answer:

/// When applicable, converts a [DOS device path](https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats#dos-device-paths)
/// to a normal path (usually, "Traditional DOS paths" or "UNC path") that can be consumed by the `import`/`require` syntax of Node.js.
/// i.e. Remove `\\?\`, `\\.\` prefix then `\\?\UNC` prefix.
/// Code adapted from <https://stackoverflow.com/questions/50322817/how-do-i-remove-the-prefix-from-a-canonical-windows-path>
#[cfg(target_os = "windows")]
#[inline]
pub fn dunce(p: PathBuf) -> PathBuf {
    let p = p.strip_prefix(r#"\\?\"#).map(|p| p.to_path_buf()).unwrap_or(p);
    let p = p.strip_prefix(r#"\\.\"#).map(|p| p.to_path_buf()).unwrap_or(p);
    dunce::simplified(&p).to_path_buf()
}

CodSpeed Performance Report

Merging #455 will not alter performance

_{Comparing chenxinyanc:xinyan-strip-prefix (d46a428) with main (b9f1c67)}

Summary

✅ 3 untouched benchmarks

I think the tricky part is, node JS cannot handle imports from either of these paths (even though ordinary fs operations still work).

r"\\?\Volume{c8ec34d8-3ba6-45c3-9b9d-3e4148e12d00}\file4.txt"
r"\\?\BootPartition\file4.txt"

In these cases, we might need to keep the symlink as-is, and that's what I was trying to describe in #454, which is to prevent resolving (or following the link target of)

D:\unrs-resolver-mounted-partition\src\mount-root\foo.ts

into

\\?\Volume{c8ec34d8-3ba6-45c3-9b9d-3e4148e12d00}\foo.ts

because NodeJS cannot import from the second path, but it can import from the first path.

That's also why I'm letting strip_windows_prefix return an Option<PathBuf> instead of PathBuf itself.

Probably you can check whether the &Path passed from dunce::simplified still starts with \\?\ or \\.\ to decide whether not to follow the symlinks.

btw we might need to strip the r"\\?\" part even if the corresponding traditional DOS path exceeds 260 chars. Because while NodeJS supports importing from long paths since nodejs/node#50753 , it still does not support DOS device path (path starting with \\?\). I've made a mistake here. However, you might need to consider whether you still want to keep stripping the \\?\ prefix even if the path exceeds 260 chars.

This case might not have been handled by dunce itself.

https://gitlab.com/kornelski/dunce/-/blob/master/src/lib.rs?ref_type=heads#L180-182

I've just given the following module path a try

r"\\?\D:\test\long long long long path\long long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long path\test test test test test.js"

While we cannot represent the path above as a "valid" traditional DOS path, because the length of r"D:\test\...\test test test test test.js" would exceed 260 chars, NodeJS still supports its import

Welcome to Node.js v22.7.0.
Type ".help" for more information.
> require("D:\\test\\long long long long path\\long long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long path\\test test test test test.js")
{}
> await import("file:///D:\\test\\long long long long path\\long long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long path\\test test test test test.js")
[Module: null prototype] { default: {} }
> require("\\\\?\\D:\\test\\long long long long path\\long long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long pathlong long long long path\\test test test test test.js")
{}
// I couldn't figure out a valid `file:///` URI with DOS device path (\\?\...) to use `await import`.

I'll come back to this PR when I get the time.

I'll come back to this PR when I get the time.

Please take your time.

However, I think my version should be a practically working one, which might be a good place to get started, before we receive other feedbacks in the long run.

@chenxinyanc I think you can PR to unrs-resolver first and resolve your issue quickly, and I'll sync with upstream changes later.

Thanks @JounQin ! I'll cherry-pick the PR and probably we can see how it turns out in unrs-resolver first.

Sorry I went too far trying to optimize this thing, reverted my changes and cleaned up the code structure instead.

@Boshen Sorry for the flurry but it seems my prior change in this PR is not sufficient to fix my issue: unrs/unrs-resolver#84 (comment)

I've just tried the binary built from 5fc3395 in this repo locally and confirmed the same outcome.

No need to worry at this point, though. IMO this is not exactly a regression:

• Before this PR: ResolverFactory.resolve returns invalid module path (with Volume{...} segments)
  • This will eventually cause downstream consumers to get a non-existent path and report mysterious errors (e.g. path not found).
• After this PR: ResolverFactory.resolve returns Err(PathNotSupported)

Since I've already added some changes today in the downstream PR: unrs/unrs-resolver#84, I will probably open another PR here in oxc-resolver when I'm ready. My plan would be

• we keep the PR (in unrs-resolver) a draft PR, and
• when I'm done with conflict resolution and unit tests in this PR, I open a PR in oxc-resolver with the same change, and
• after the PR gets accepted in oxc-resolver, (JounQin) just need to do a simple merge-upstream, and
• eventually, we close the PR in unrs-resolver without needing to merge it.

Sorry for the troubles 🌚 things should have been simpler if I had stuck to making changes in oxc-resolver repo instead.

@Boshen Sorry for the flurry but it seems my prior change in this PR is not sufficient to fix my issue: unrs/unrs-resolver#84 (comment)

I've just tried the binary built from 5fc3395 in this repo locally and confirmed the same outcome.

No need to worry at this point, though. IMO this is not exactly a regression:

• Before this PR: ResolverFactory.resolve returns invalid module path (with Volume{...} segments)

  • This will eventually cause downstream consumers to get a non-existent path and report mysterious errors (e.g. path not found).

• After this PR: ResolverFactory.resolve returns Err(PathNotSupported)

Since I've already added some changes today in the downstream PR: unrs/unrs-resolver#84, I will probably open another PR here in oxc-resolver when I'm ready. My plan would be

• we keep the PR (in unrs-resolver) a draft PR, and
• when I'm done with conflict resolution and unit tests in this PR, I open a PR in oxc-resolver with the same change, and
• after the PR gets accepted in oxc-resolver, (JounQin) just need to do a simple merge-upstream, and
• eventually, we close the PR in unrs-resolver without needing to merge it.

Sorry for the troubles 🌚 things should have been simpler if I had stuck to making changes in oxc-resolver repo instead.

Sounds good to me.