You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
Initial checklist
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 avfile-fetch
too?Also, URLs as strings are problematic: passing
url.href
tofs.writeFile
will write afile/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!
The text was updated successfully, but these errors were encountered: