[ROADMAP] Plugin architecture in the works?

[jameswomack]

Background on this issue

1. 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
2. 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

[osdevisnot]

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 [Feature] Toggle contenthash for all output filenames evanw/esbuild#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.

[jameswomack]

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?