Proposal : allow to use an 'io/fs.FS' as an input file system

[LeGEC]

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 :

• have the content of node_modules/ read from a single .zip or .tar.gz archive, rather than from actual files on disk
• run esbuild on a server, from buffers in RAM presented as a fs.FS

[evanw]

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 io/fs.FS interface.

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.

[progrium]

Do you have any idea how obnoxious it is to have this in Go and not follow Go idioms and interfaces?

[LeGEC]

@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

[progrium]

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.