A unified system of serving and building

[justinfagnani]

I've been using @web/dev-server and @web/test-runner in a number of different context and I'm seeing some setup and config friction that I think could be solved with a unified approach across the tools, and possibly some really nice DX improvements in other areas if that's done.

The main part of the config at the heart of @web/dev-server: node-resolve settings, plugins, etc., is already used for the dev-server, obviously, but also in @web/test-runner because it needs to serve files for tests. But these two don't share a config by default...

@web/dev-server can also be used in an app dev server - that is a Koa app that has endpoints for various server APIs and a static file route.

And once you have a setup that can serve your JS files, that's a good description of what you need to build the files for production. Currently that doesn't share a config by default, and some things are harder because there are Rollup plugins, vs things that are built-in (even if using Rollup plugins) like import resolution.

I think it would be really nice if the JS/static-file handling was unified and integrated in a few common workflows and tools:

• A standalone dev server (WDS)
• A standalone test runner (WTR)
• Koa, Express, etc. middleware to add dev-server static file handling to app servers.
• A build tool that runs Rollup with optionally additional bundling and minification on top of the dev setup, link prefetch injection, etc.

All of these tools can share the same core JS handling config, and give a clear workflow on how to setup dev/test/prod.

I might even be nice to have a single CLI for the standalone commands. Maybe a @web/cli package with web serve, web test, web build.

[bennypowers]

As long as it has facility for plugins

[daKmoR]

I sort of have something like this for rocket...

e.g. you add a rollup plugin once and it is used by the server and the rollup production build

https://rocket.modern-web.dev/docs/basics/configuration/

[justinfagnani]

@bennypowers

As long as it has facility for plugins

Would this be any different from what WDS and WTR already support?

[bennypowers]

it wouldn't, as long as the new thing doesn't prevent users from tapping in to the existing plugin system