-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
refactor: use Url in deno dir #2572
refactor: use Url in deno dir #2572
Conversation
b23c971
to
d52d870
Compare
Note to self: our current resolving of paths (including These specifiers are not resolved properly on windows:
Consider using |
4e2008e
to
e9efe59
Compare
e9efe59
to
e02d816
Compare
Rebased on top of #2581 |
3367275
to
2f063ec
Compare
@ry @kitsonk please review - this PR is meant to replace use of During work on this PR I've got pretty good idea how to rewrite DenoDir, but I'll write up my thoughts in appropriate issue. @kitsonk I'd very much would like to help you out during rewrite of you'd want. |
match self.fetch_module_meta_data(script_name, true, true) { | ||
// TODO: this method shouldn't issue `fetch_module_meta_data` - this is done for each line | ||
// in JS stack trace so it's pretty slow - quick idea: store `ModuleMetaData` in one | ||
// structure available to DenoDir so it's not fetched from disk everytime it's needed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
@bartlomieju This is a great patch and it looks good except for a few nits
Great. I look forward to it. |
@piscisaureus I merged latest master |
core/module_specifier.rs
Outdated
UnsupportedPathPrefix => write!( | ||
f, | ||
r"invalid path prefix, must be disk prefix (eg. C:/, C:\\)" | ||
), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Messages for these two variants should print out specifier and path respectively.
ImportPathPrefixMissing(ref specifier) => {
write!(f, "Invalid import path: \"{}\". Relative import must be prefixed with / or ./ or ../", specifier.to_str().unwrap())
}
UnsupportedPathPrefix(ref path) => {
write!(
f,
"Unsupported path prefix: \"{}\". Must be disk prefix (eg. C:/, C:\\\\)",
path.to_str().unwrap()
)
},
Trying to figure it out, but neither String
nor PathBuf
implement Copy
trait... 🤔
LGTM from me. @piscisaureus - approve and land when you're satisfied. |
Still waiting for my windows machine. ETA now: tomorrow. Hang in there. |
@piscisaureus any update? |
I'm actually not so happy with the logic that decides whether a command-line argument is a path or a URL. What I would suggest is the following
With that you can remove all windows-specific path handling and let rust-std deal with it, which seems to do it well. |
@piscisaureus that is exactly what happens at the moment. The only Windows-specific thing is |
Sorry, but it's really not right. Take this change for example: /// Resolves module using this algorithm:
/// https://html.spec.whatwg.org/multipage/webappapis.html#resolve-a-module-specifier
pub fn resolve(
specifier: &str,
base: &str,
) -> Result<ModuleSpecifier, ModuleResolutionError> {
use ModuleResolutionError::*;
// 1. Apply the URL parser to specifier. If the result is not failure, return
// the result.
if let Ok(module_specifier) = ModuleSpecifier::resolve_absolute(specifier) {
return Ok(module_specifier);
}
...
} ModuleSpecifier::resolve_absolute will first try to interpret the specifier as a path, and then fall back to parsing it as a URL only if that fails. |
I'll try to pump out a patch tonight that does it correctly. |
562e61d
to
d034ff4
Compare
/// We additionally require the scheme to be at least 2 characters long, | ||
/// because otherwise a windows path like c:/foo would be treated as a URL, | ||
/// while no schemes with a one-letter name actually exist. | ||
fn specifier_has_uri_scheme(specifier: &str) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was gonna argue that trying path first before parsing URL was to handle Windows path prefixed with disk, but as always your solution is much more elegant 👍 kudos @piscisaureus
d034ff4
to
d0447c6
Compare
@ry, @bartlomieju |
dd42e3f
to
d0447c6
Compare
The rules are now as follows: * In `import` statements, as mandated by the WHATWG specification, the import specifier is always treated as a URL. If it is a relative URL, it must start with either / or ./ or ../ * A script name passed to deno as a command line argument may be either an absolute URL or a local path. - If the name starts with a valid URI scheme followed by a colon, e.g. 'http:', 'https:', 'file:', 'foo+bar:', it always interpreted as a URL (even if Deno doesn't support the indicated protocol). - Otherwise, the script name is interpreted as a local path. The local path may be relative, and operating system semantics determine how it is resolved. Prefixing a relative path with ./ is not required.
d0447c6
to
72d9045
Compare
"file:///home/yeti/deno", | ||
"file://server/some/dir/file", | ||
), | ||
// This test is disabled because the url crate does not follow the spec, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@piscisaureus LGTM. I like your solution to |
Follow-up to #2559 (and blocked by it)
Use
Url
instead ofString
for specifiers in//cli/deno_dir.rs