Skip to content
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

Closed
m13t opened this issue Feb 12, 2023 · 4 comments
Closed

Support for io/fs.FS interface in Go API #2912

m13t opened this issue Feb 12, 2023 · 4 comments

Comments

@m13t
Copy link

m13t commented Feb 12, 2023

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.

@evanw
Copy link
Owner

evanw commented Feb 12, 2023

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.

@evanw evanw closed this as not planned Won't fix, can't repro, duplicate, stale Feb 12, 2023
@m13t
Copy link
Author

m13t commented Feb 13, 2023

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?

@evanw
Copy link
Owner

evanw commented Feb 13, 2023

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 package.json files.

@m13t
Copy link
Author

m13t commented Feb 13, 2023

No problem, I'll keep an eye on #690 for the future. Thanks @evanw.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants