-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Proposal : allow to use an 'io/fs.FS' as an input file system #1704
Comments
The interface for the Go API is deliberately as identical as possible to the JS API. Nothing will be added to the Go API that doesn't also make sense for the JS API, since the JS API is the primary use case and the Go API is the secondary use case. So I won't be adding the The request for a virtual file system has come up before: #690. I'm going to close this issue as a duplicate of that one. |
Do you have any idea how obnoxious it is to have this in Go and not follow Go idioms and interfaces? |
@progrium : hi there Although I do see something that looks like sympathy towards the suggestion I made, I must say I'm not very fond of the tone in which you "promote" that suggestion. Perhaps you could reword your sentence, either by saying you would like to see this implemented (for that, a simple "+1" on the original message is already an indication), or by giving your own example of how this would serve your purposes ? Cheers |
It was my intention to communicate my extreme frustration with the general decision to de-prioritize making the Go code of this project more useful to the Go ecosystem. It was with more restraint than you think. |
When calling esbuild from the API, it would be a nice addition to be able to load code from something else than an actual mounted file system.
Two example usage :
node_modules/
read from a single.zip
or.tar.gz
archive, rather than from actual files on diskesbuild
on a server, from buffers in RAM presented as afs.FS
The text was updated successfully, but these errors were encountered: