-
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
Isomorphic local file fetching #45798
Comments
I considered opening the issue on the Undici repository, but it seemed an important enough potential change to be worth being discussed here. |
This could help to make isomorphic WASM modules, right? |
Yes, it's one of the use cases I have in mind. Another is to load the non-JS non-JSON files that often get parsed at runtime to avoid build steps - for example the tmLanguage files in projects that deal with syntax highlighting, or csv files, etc. |
/cc @nodejs/undici I vaguely remember a discussion about supporting |
This doesn't have much chance of being implemented in undici until the discussions from nodejs/undici#1239 are resolved. I'd like to sum the discussion above up, so it's easier to link to this issue in the future. Let's take a look at the two environments that implement some form of file url fetching; Deno and Firefox. Firefox has a permission system where a user can allow/deny access to a certain file, along with other things like CORS and CSP. Deno has a permission system which lets the user allow/deny access to certain files or directories. Node... doesn't - or at least not one that would make everyone happy. Along with this, enabling it by default can be dangerous. For example, someone might create a CORS proxy that takes a url, fetches it, and returns the result with the proper headers. If file urls could be fetched, it creates a potential vulnerability. This was pointed out in wintercg/fetch#5. Then, if we decided to implement it, the spec doesn't include how to handle file urls: "For now, unfortunate as it is, file: URLs are left as an exercise for the reader." What headers would we have? What error would throw if the file doesn't exist? All of this could create incompatibilities between implementations, and ensures that there will be issues in the future. Considering that node has the ability to read files -- and is much faster than using fetch directly -- I cannot see this being added. At one point I did want to add this ability to undici, but with the reasons above, I am against it. |
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment. For more information on how the project manages feature requests, please consult the feature request management document. |
What is the problem this feature will solve?
The JavaScript ecosystem has no way currently to load a file next to the current script in an isomorphic manner.
In Node:
In browser:
In bundlers:
These methods all conflict with each others.
What is the feature you are proposing to solve the problem?
The
fetch
implementation in Node (ie Undici) should support a basic way of loading localfile://
urls.What alternatives have you considered?
This could also be solved by making browsers support for
fs.promises.readFile
, but that seems entirely unthinkable.Another option would be to add another primitive, less complex than
fetch
, sayimport.meta.loadFile
. This would still require discussion with browsers, and to wait a couple years for it to be standardized and made available - if ever.A third option, perhaps cleaner, would be to use import assertions to spec that directly into the language. The main problem is that it'd still have some of the problems of the first alternative, by not being available for a potentially very long time - whereas adding
file://
support to Undici seems something that could be done relatively easily.The text was updated successfully, but these errors were encountered: