sorvor
                                
                                 sorvor copied to clipboard
                                
                                    sorvor copied to clipboard
                            
                            
                            
                        [ROADMAP] Plugin architecture in the works?
Background on this issue
- I'm very appreciative of sørvør & am finding it very promising/useful. I've tried:
- @web/dev-server + esbuild
- esbuild --server ...neither worked with my prototypical codebase. sørvør, despite being written in a different language than my project, worked right out of the box. I especially appreciate the ability to pass through any arguments to esbuild—an ability that many projects neglect
 
- Being able to use directives in html immediately made me think of a potential plugin architecture. In digging into the sørvør source I came across this block of code—that looks like an ideal place to pull in custom directives (e.g. hmr or workbox/ServiceWorker)
Question
With that background: Are you working toward a plugin architecture / opportunity for extensibility? The ability to add the aforementioned capabilities (perhaps w/ the ability to intercept HTML requests) would round out sørvør's viability for my team's use case. I've not done production Go language programming yet but I intend to pick it up in order to contribute... & I wan't to see if that work could be done within sørvør or would need to be done on top of it
Thank you for detailed background on this issue @jameswomack - really appreciate it.
I haven't fully flushed out roadmap for sorvor yet, but I want to add below features at the minimum.
- asset fingerprinting - this will enable you to create unique file name for given entry point. see https://github.com/evanw/esbuild/issues/518
- auto workbox gen for SPA - this will enable progressive web apps out of the box.
That said, I do not want to complicate this setup with HMR - in my mind the build speeds with sorvor are fast enough for development without HMR.
Generally, golang being statically linked, it's harder to create plugin system. But I am willing to consider a feature that might be beneficial for the project.
Are you looking for something specific for your team/project use case.
Thanks for the response @osdevisnot Asset fingerprinting & workbox autogen will be great!
The team I work on develops a build CLI that bundles components & applications for delivery within a custom platform (incl. a backend that serves assets in different ways depending on configuration generated by the build). Anyway, given that sørvør uses esbuild, perhaps some|most of that could be implemented in the esbuild plugin system
At this investigation stage, it would be nice to have a way to add custom routes to the server w/o needing a reverse proxy. But as long as it's possible to setup a reverse proxy that works well w/ sørvør, that's not a blocker
I'm a Go newb, but I did come across this esbuild issue that references this go plugin solution. In your experience, might RPC be a valid avenue for implementing Go plugins?