fix: ModuleSpecifier removes relative path parts

[bartlomieju]

Fixes #6387

[bartlomieju]

I'm not happy copy-pasting normalize_path method to core/module_specifier.rs but I don't have a better idea for fix of this issue...

[piscisaureus]

LGTM

I'm a bit surprised this wasn't already done, because the W3C/Whatwg URL specification mandates this behavior, and I would expect the url crate to implement that part of the spec.

Or is the situation here that file imports are never converted to a url?

(If so, that might give me some concern, for example are we correctly unescaping /hello%20world/banana to /hello world/banana?)

[bartlomieju]

I'm a bit surprised this wasn't already done, because the W3C/Whatwg URL specification mandates this behavior, and I would expect the url crate to implement that part of the spec.

I would also expect Url crate to have this behavior, but it seems that's not the case - in Rust's standard library the only method that can remove ./ and ../ segments is std::fs::canonicalize which resolves symlinks...

Or is the situation here that file imports are never converted to a url?

Not sure what you mean, this behavior occurs when you use ModuleSpecifier::resolve_url_or_path() with a relative path that has ./ or ../

(If so, that might give me some concern, for example are we correctly unescaping /hello%20world/banana to /hello world/banana?)

When should we unescape this? But I believe this is handled by Url properly.