-
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
Support for io/fs.FS interface in Go API #2912
Comments
I'm not planning on doing this. Other people have already asked for this, and you can see my reply here: #1704 (comment). Basically the JS API is primary and the Go API is secondary. The Go language was originally an internal implementation detail. People requested that I expose esbuild's internal Go API so I did, but the Go API surface is deliberately locked to the JS API surface. I may expose a file system API in the future to fix #690, but it may look very different than Go's io/fs.FS interface since JS performance across the IPC boundary is important. If that is ever implemented, then esbuild's Go file system API will intentionally be similar to esbuild's JS file system API. |
Apologies for the duplicate ticket, I clearly failed when searching if it had been covered already. I appreciate the explanation and i understand the reason for keeping the APIs as aligned as possible. I suppose the FS interface was just an example given it’s an existing interface but if any kind of implementation comes in the future for virtual file system support then it would be welcomed. Would you consider providing an example plug-in in the documentation like you do for HTTP and Wasm? |
I'm not going to provide an example plugin for this because there isn't really a way to do this right now (even with plugins), which is why #690 is still open. You can use plugins to intercept import paths in files but you can't currently use plugins to intercept other file system lookups that esbuild makes such as those for |
Hi @evanw,
Really like the Go API for esbuild but I’ve been having some difficulty getting it to play nicely with Go’s native embedded files which implement the standard FS interface. Had some minor joy with a horrendous plug-in that fakes the resolve step and loads the contents from the FS but it’s a bit clunky, particularly where directories are concerned.
The alternative at this point would be writing out to the file system to a temp directory from there but being able to pass in an FS instance seems like a cleaner option.
I noticed in the internal packages you have an FS interface which is not compatible and also not exposed to consumers of the package but I’m wondering if it might be possible for some of this to be opened up somewhat or possibly creating an interop wrapper and additional method that would allow for dealing with FS instances rather than expecting files to be on a physical OS path.
This would be particularly useful given that people could then also integrate with Afero library to have a multitude of flexibility in where content comes from when building via the Go API.
The text was updated successfully, but these errors were encountered: