-
Notifications
You must be signed in to change notification settings - Fork 135
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
Preload providers #302
Preload providers #302
Conversation
I would hope/expect that if vfsgen is still an actively maintained library, they'll have interest in making it compatible with the native interfaces. Either way though I wouldn't worry about this too much until the proposal is actually implemented and available in a stable Go version. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left you some comments inline, the most important one being about the panic.
From practical stand point I would probably only stick to the official providers for now as the generated file already has 3.5M. I think it's a reasonable cost to pay for better UX 👍 , but we have to keep in mind that maintaining bigger files in the repo can negatively affect the longer-term developer experience (nobody enjoys cloning large repositories) and potentially also end-user UX (nobody enjoys downloading large binaries).
368731e
to
378e0d5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I apologise ahead for the conflicts, but I'd recommend merging #307 first and rebasing this PR.
081e780
to
76e6278
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
🚢
Co-authored-by: Radek Simko <[email protected]>
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
This PR creates a generate directive to
May depend on #301
TODO
vfsgen uses a common pattern of alike tools in working with the http.FileSystem interface. It would be nice to find an alternative that can follow the new embed proposal, which builds off the new filesystem proposal (something we have begun to adopt). Perhaps we could fork vfsgen and reimplement it to work with the proposed types.
Closes #292