Dev server middleware?

[FredKSchott]

Spin off of modernweb-dev/web#471
/cc @LarsDenBakker @benmccann

Since Snowpack's dev server is implemented directly on top of the http server, it wouldn't be too hard to expose our Dev Server as a middleware function for Express and Koa.

This is interesting because it's not about "adding dev-server functionality to Snowpack" (the previous lens we've looked at this from) but instead about "I want to build a dev server on top of Snowpack." Could Sapper, Next.js, [FAVORITE SSR METAFRAMEWORK™️] build on top of Snowpack if we provided middleware for their server?

[benmccann]

Sapper povides a middleware for Express (or Polka, etc.) that the user includes in their server. Sapper runs a process that includes Rollup as a library and runs a Rollup file watcher. Then when you change a file it creates a couple files such as your router (based off the layout of components on your filesystem), and finally bundles the client and server.

I think the biggest question for Sapper is how to create the application files such as the routing manifest. Right now that's in the Sapper dev server process. I'm not sure whether that's the best place to do it and also think it might be a bit slow at the moment.

I guess I haven't really answered your question, but thought it would be useful to share some background about how it works today and where the largest priorities are. I'm pretty time-constrained and haven't gotten to look at the dev server story much. I think @rixo and @dionysiusmarquis have perhaps investigated it a bit

[FredKSchott]

That's super helpful! Interesting that you all provide a middleware as well, feels like +1 point for that being a good idea for us as well.

[stramel]

@FredKSchott This is actually something I was planning on trying to accomplish with the dev server testing too. I'm +1 to middleware

[dionysiusmarquis]

When I started the Sapper/Snowpack POC I started a middleware implementation for Snowpack which can be found here: #430

[overlookmotel]

Hi. Just to add my penny's-worth, Webpack's dev server middleware is what's keeping me with Webpack rather than switching to Snowpack (which I would otherwise be keen to do).

[FredKSchott]

@overlookmotel just to be clear, do you mean this: https://webpack.js.org/guides/development/#using-webpack-dev-middleware ?

[overlookmotel]

@FredKSchott Yes, that's what I meant.

While I know you can ask Snowpack to proxy API requests to another server, I prefer to run one process which (1) serves the API natively and (2) passes requests for front end assets to a dev middleware - rather than the other way around with the dev server "at the front".

For a bit more context, this is what I'm doing:

My app dynamically creates some of the modules which comprise the front end code at run time. For example, in a React app, the components for all the pages are files on disc, but the app dynamically creates a component for the router (much like NextJS, but in my case using react-router-dom).

So, in dev mode, my app needs to be able to inject this dynamically-created router "file" (which is actually not a file on disc but in memory) into the dev server.

This is possible with Webpack as you can run the dev server in process and dynamically inject modules into Webpack's input pipeline using webpack-virtual-modules.

Apologies if I'm misunderstanding, but I don't think this is possible at present with Snowpack.

I know that a dev middleware wouldn't be the whole story to make this possible, but if Snowpack was running in my app's process, I imagine I could hack my way to "virtual modules" by shimming Node's fs module with something like memfs so the "virtual" files appear as real files to Snowpack's watcher.

Perhaps this use case is a bit niche so not worth supporting, but I just thought I'd let you know of this other possible use for a dev middleware, since you're scoping it out.

[jeberly]

While I know you can ask Snowpack to proxy API requests to another server, I prefer to run one process which (1) serves the API natively and (2) passes requests for front end assets to a dev middleware - rather than the other way around with the dev server "at the front".

We do something similar, but we simply serve up the files that rollup outputs in dev mode from our API server so we can have the same CSP headers with trusted types in dev that match production. The API is hosted on same domain:port as the svelte static files.

I was trying to see if we could migrate to snowpack, but I can't seem to figure out how to accomplish the above. I think I would just need an option to output the js/html/css assets to disk, instead of in memory. But best I can tell snowpack doesn't support that?

[stramel]

I was trying to see if we could migrate to snowpack, but I can't seem to figure out how to accomplish the above. I think I would just need an option to output the js/html/css assets to disk, instead of in memory. But best I can tell snowpack doesn't support that?

@jeberly I think you would be looking for the --watch option for now until we have a middleware. You can then serve the files from your server.

[FredKSchott]

Yes! snowpack build --watch is exactly what this is for.

[jeberly]

@FredKSchott @stramel Thanks guys! That was exactly what I was after.

We have a custom ws connection and file watcher that reloads app on changes atm, but I was hoping to see if I can get snowpack build --watch to run the HMR server as mentioned in #782 (comment). But I am entirely new to the codebase, so I am not sure the level of effort involved there yet.

[FredKSchott]

build --watch --hmr has been requested by enough people that I think it's clearly a useful task to prioritize. Will spin up an official issue to see if anyone is interested in tackling!

Edit: Spun off in #1002

[FredKSchott]

/cc @jeberly build --watch --hmr was just merged in #1002

[samwightt]

Is there any update on this? build --watch --hmr is great, but it's not a proper substitute for server middleware like Vite's. Really would love to use Snowpack for a new project I'm starting (esbuild is amazing), however the lack of proper middleware is kinda holding me back.