-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
url.pathToFileURL should not dedup '/' in path #35507
Comments
@bmeck ... is this a spec issue or an issue with our implementation? |
@jasnell our helper function converting between the 2 (URL and path) seems broken |
I'd argue this is by design. A path has deduplicated |
@guybedford I think it could be argued in either direction for different reasons, but to me the lossy behavior being only on 1 end is both odd and a bit hard to explain. The real oddity to me here is that if a filesystem were to exist that did support empty filenames (S3 for example supports this) it would be odd to normalize in the runtime rather than leaving it to the OS. Is there a reason to impose a normalization step that might not be universally respected? I agree that this can cause distinct differences since that would cause issues like the one mentioned above with the new WHATWG change, but I think consistency is paramount personally. If we do want to normalize we should probably change |
To be honest I think we've hit a real gap here between the spec and the reality, and siding with the spec only continues to ignore reality. |
Specifically, I think we should add a new URL normalization function ( I don't see any issue though with this function being lossy. Lossiness is a feature not a bug. |
One could even define |
@guybedford given we are now moving to relying on realpath for our default loader, and talking of manual deduping for --preserve-symlinks would it be safe to move forward here? My main goal is that if an OS doesn't remove the |
@bmeck there is more than just this deduping at play here - |
@guybedford that seems like the internal usage of |
@bmeck the |
@guybedford my goal is to have these 2 complimentary functions do the same kind of normalization. I'm not against some normalization, but altering fileURLToPath to remove |
@bmeck if the goal is consistency, would you consider the alternative of normalization on the |
@guybedford possibly; but, since |
That sounds sensible to me. |
This issue seems to characterize the bug as related to the spec, but this is not true. We can either stop using |
@TimothyGu how are you hitting these limitations currently? It would help to relate the issue to a use case. |
I'm not hitting these limitations myself. I just noticed this open issue which seems to say that the WHATWG URL spec causes '/' to be collapsed, while it's really just path.resolve. |
Agreed it is separate, I guess I would effectively still argue that the file URL protocol should already handle this (in contrast to non file URL protocols). |
Found while checking: #35429
Currently it is not possible to have a path represent the file URL
new URL('file:///a//b')
when going throughurl.pathToFileURL
.url.fileURLToPath
does property preserve the//
in the path already. This causes round trips to be lossy.What steps will reproduce the bug?
How often does it reproduce? Is there a required condition?
Always
What is the expected behavior?
What do you see instead?
Additional information
The text was updated successfully, but these errors were encountered: