I was hoping the Webpack 5 update would fix this, and having the hash in the URL does help avoid some errors, but there's still an issue here.
The primary thing is that it appears Vercel only hosts the current build's assets, so if you open devtools, and then we deploy, and then you perform an action that needs to load a bundle, it will fail because the bundle for that build no longer exists in the new deploy's assets. Now with the hash in the URL, instead of loading a file with the same name that has the wrong contents, we fail to load entirely, which at least makes it clearer that something is going wrong. This is what leads to
ChunkLoadErrors we're seeing in Sentry.
Secondly, our current routes mean that if you try to load a script and it doesn't exist, instead of getting a 404, we serve our
index.html. So for instance if you load https://app.replay.io/82.615bf96308cfcc931130.js, you get the library view. This is what's leading to the
Unexpected token '<' errors in Sentry.
For example, currently https://app.replay.io/82.6fe265211f12860bb99c.js returns JS for the current build, and https://app.replay.io/82.615bf96308cfcc931130.js returns the HTML for the index.
I would not be surprised if most of the errors in Sentry are my own sessions, because I use
, and it appears that with our current caching setup, it pulls up my most recent Replay page HTML from cache, as well as
main.*.js, but when that scripts tries to run, it pretty much immediately tries to load more bundles and I guess those aren't in the cache and thus if a deploy has happened between the time that I closed the browser and opened it again, the requests all get HTML back instead of 404ing, and I end up with this:
Sentry issue: DEVTOOLS-VW