- Rename `public` -> `client` so it doesn't get copied automagically as-is (without hashes which we want for cache busting), https://vitejs.dev/guide/assets.html#the-public-directory
- We still build the version files to `public/` so their copied as-is and Vite handles it for us (so we can use `emptyOutDir`)
- Use a multiple entrypoint `.js` Vite build so things can be more intelligently bundled and take less time
- We aren't using library mode because it doesn't minify or bundle assets
- Using hash asset tags for cache busting. Hash of the file included in the file name
- We lookup these hashed assets from `manifest.json` that Vite builds (https://vitejs.dev/guide/backend-integration.html) to serve and preload
- In terms of optimized bundles, I know the current output isn't great now but will have to opt to fix that up separately in the future. Tracked by https://github.com/matrix-org/matrix-public-archive/issues/176
It seems like the `build/` directory is ignored in the GitHub file
finder as a sane default for people who put compiled assets there.
`build-scripts/` probably makes more sense anyway
1. Add surrounding messages to the given messages so we have a full screen of content to make it feel lively even in quiet rooms
- As you scroll around the timeline across different days, the date changes in the URL, calendar, etc
2. Add summary item to the bottom of the timeline that explains if we couldn't find any messages in the specific day requested
- Also allows you to the jump to the next activity in the room. Adds `/:roomId/jump?ts=xxx&dir=[f|b]` to facilitate this.
- Part of https://github.com/matrix-org/matrix-public-archive/issues/46
3. Add developer options modal which is linked from the bottom of the right-panel
- Adds an option so you can debug the `IntersectionObserver` and how it's selecting the active day from the top-edge of the scroll viewport.
- In the future, this will also include a nice little visualization of the backend timing traces
Follow-up to https://github.com/matrix-org/matrix-public-archive/pull/36
Render pipeline separation of concerns:
1. Run in `child_process`
2. Hydrogen render
It's now just a generic `child_process` runner that runs the Hydrogen render in it. This eliminates the windy path of the 1-4 steps that was only held together by the file names themselves.
OpenTelemetry tracing so we can see spans where the app is taking time.
For the user, we specifically show the spans for the external API HTTP requests
that are slow (so we know when the Matrix API is being slow).
Enable tracing:
- `npm run start -- --tracing`
- `npm run start-dev -- --tracing`
What does this PR change:
- Adds OpenTelemetry tracing with some of the automatic instrumentation (includes HTTP and express)
- We ignore traces for serving static assets (just noise)
- Adds `X-Trace-Id` to the response headers
- Adds `window.tracingSpansForRequest` which includes the external HTTP API requests made during the request
- Adds a fancy 504 timeout page that includes trace details and lists the slow HTTP requests
- Adds `jaegerTracesEndpoint` configuration to export tracing spans to Jaeger
- Related to, https://github.com/matrix-org/matrix-public-archive/issues/26
Eric Eastwood