[Question] Are you open to having a live reload section?

[zaydek]

Hi @evanw. Are you open to a pull request that documents how to implement a minimally viable rapid development / live-reload server? I’d be happy to submit a PR that explains the following:

1. Implement a minimal file watcher using a simple poll-based strategy (Go)
2. How to incrementally recompile esbuild based on file changes
3. How to use SSE (server-sent events) so the client browser tabs reload themselves when incremental recompilation is done

Your serve implementation helped me understand why a) native file watching can be a bad idea and b) how to strategically use HTTP servers to delay requests to prevent race conditions, etc., but it didn’t demonstrate to me how to make esbuild respond to filesystem changes and trigger reloads on client browser tabs.

I’d like to help document implementing this kind of dev server architecture from scratch in a few paragraphs with Go code examples.

No worries if you’d rather not, I just thought I’d try to help where I can be usefuk.

Relevant links:

• Implementing platform-independent, poll-based file watching in Go

  If you’re like me and want the simplest form-factor that you can actually understand / debug yourself, you can roll your own naive watcher in Go in <50 LOC:

  • Code: [MVP] Watch mode evanw/esbuild#21 (comment)

• MVP dev server: How to integrate react-refresh in esbuild to implement hmr ? evanw/esbuild#645 (comment)

  So I figured out how to implement esbuild incremental recompilation + server-sent events to trigger reloads which feels like HMR but works today. I used this playground to validate my ideas: https://github.com/zaydek/esbuild-dev-server.

  • Playground: https://github.com/zaydek/esbuild-dev-server

[zaydek]

I’ll close this since this feature has been added to 0.8.38!