Use URLs instead of paths

[wooorm]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Problem

It would be nice to go all in on a format that is supported everywhere: URLs.
Instead of a platform dependent (unix vs windows) string.

However, URLS are broader than what we support, what should we do when URLs point to data:? https://? Etc?
We could change to-vfile -> vfile-fs and add a vfile-fetch too?

Also, URLs as strings are problematic: passing url.href to fs.writeFile will write a file/Users/User/whatever/ folder in CWD. This could be confusing to users.
This means our API has to likely return URL objects instead of strings. But that has again the problem of being either slow or a reference.

It’s a bit harder with URLs to change folders or extensions. Our current getter/setters are a nice alternative.
We could drop those getters/setters, maybe go with some utilities exposed from here to get/set stuff?

Extensions are typically meaningless in URLs anyway. Perhaps we’d need to have mimetypes?

Maybe we could first inspire from, and later depend on / add onto https://developer.mozilla.org/en-US/docs/Web/API/File?

Solution

?

Alternatives

Many!

[remcohaszing]

Where exactly? This issue is created specifically on the vfile-message repo, but this package doesn’t use paths.

For reading I think it’s best to follow Node.js logic: A string represents a path, file URLs are also allowed.

I don’t think we need vfile-fetch, but it’s fine to create it.

I’m all for being closer to the standard File API. The downside is that it’s methods are async though.

[wooorm]

oh whoops was supposed to go in vfile!