feature request: create end-to-end dev serving solution with esbuild

[vladmandic]

big established bundlers have (to some level) capability to monitor sources for changes and rebuild/rebundle as needed.
additionally, for web development it's very useful to have a simple web server to serve bundled output.

strictly speaking this is all outside of the scope of esbuild, but it would be a very useful feature for larger community.

for example, i combine chokidar for file monitoring with esbuild service to rebuild when triggered and nodejs built-in http2 module to serve it all for dev purposes: https://gist.github.com/vladmandic/9464558b5f5b583716ffba8f732f8cf2

this feature request is nothing really new or challenging, it's just about polishing it and making it easily usable for larger community.

[nettybun]

There's also #481 and #21 which discuss this. Like you said it's outside of the scope of esbuild. People can be quite opinionated about what the right way to setup a dev environment is and it adds a lot of dependencies.

[vladmandic]

of course this is just an opinion...

• there really are no added dependencies at all, all required functionality is already in nodejs: fs.watch (bit messy, but workable), http/https/http2 (works like a charm, don't need a framework like express). i even threw in zlib for gzip/brotli over-the-wire compression.

• people with strong opinions on the right way to setup a dev environment are people that know how to set it up themselves - they are not the main target for this and they can continue using their setups. main target is general community that just wants something to work out-of-the-box

[FredKSchott]

I know that this isn't exactly what you're looking for, but https://snowpack.dev/ is an opinionated dev server & build pipeline built on top of esbuild. May be worth checking out if you're interested in what tooling is growing around esbuild!

[evanw]

strictly speaking this is all outside of the scope of esbuild, but it would be a very useful feature for larger community.

I think this is actually in scope, as I wrote here: #21 (comment). Using a local server is hopefully more robust than file watching. I'm already most of the way there to an implementation of this, and of an incremental build API to go with it. Stay tuned!

[vladmandic]

great stuff!

quick comment: many newer JS browser features are not available when page is loaded via http, they require https (example is access to navigator object). or technically, http2 is even better and it only works in secure mode - and it's supported by all modern browsers.

and if page is loaded via https, loading a module using http is blocked as mixed content is being phased out (starting with Chrome 80 and progressively more aggressive since then).

perhaps adding a https server using self-signed certificate for dev server?

[nettybun]

Certs are tricky for different OSes and browsers that have different cert stores. I think if people need HTTPS they should use mkcert and a tiny reverse proxy? That's what their prod environment is going to be anyway.

[vladmandic]

Sure, that's what I have in place already, custom reverse proxy https://github.com/vladmandic/piproxy.

Goal here is to have something that works out-of-the-box for non-experienced user.

And self-signed certs are not that tricky, it can be done inside NodeJS (not talking about wrapper for mkcert or openssl). Did a library a while ago that handles certs https://github.com/vladmandic/piacme, just as an example (done ugly, primarily for personal use).

Unfortunately, APIs such as navigator that require https are too common nowadays (e.g. you can't get access to webcam without it).

[nettybun]

Goal here is to have something that works out-of-the-box for non-experienced user.

I'd argue that needing https and features like webcams are for experienced users. People are welcome to use one of the thousand existing dev servers on the market, or build their own.

Dev servers are a slippery slope, and I've sure you've seen it time and time again that someone tries to build their own dev server and cert handler which ends up being several pages of documentation on how to setup path routing to their backend, headers + cors, proxies, middleware, compression, logging, websockets, and hmr...

I don't know why that would be esbuild's job. I think it's great as a bundler that's embedded into larger packages like Snowpack to handle this use case.

This is echoed in #537 (comment); Snowpack is a great solution for someone non-experienced wanting something out of the box. It has all the complicated features I'm talking about. It's also huge. I don't mean to throw shade, it's a lovely project, but a fresh install is 224 dependencies, 1981 files, and 13.6MB of code... (via npx howfat). I think we should keep that separate.

[nettybun]

Speaking of, your own PiProxy server that you link to takes 3 screens to display an example configuration. It looks like a very useful dev server, great work! I will check it out and learn from it, but I would also be sad to see its complexity as part of esbuild...

[vladmandic]

oh, absulutely! :)
imo, esbuild should have absolute minimum for end-to-end out-of-the-box dev work and nothing more.

[evanw]

This has now been released, and is documented here: https://esbuild.github.io/api/#serve.

Good point about https. That might be the point at which it makes more sense to configure an external proxy, since certificate configuration can get pretty customized.