firebase-tools: "Uncaught SyntaxError: Unexpected token <" after firebase deploy

Yeah so it’s a cache behavior, not a bug with hosting.

The build chain for your app (Webpack, Parcel, whatever) uses whats called “cache-breaking filenames”. These are randomly generated filesnames and look a bit crazy because they are different on each build. For example, the current build references https://app.firebaseapp.com/static/js/main.d8ee1b86.js when you rebuild and redeploy you’ll now have https://app.firebaseapp.com/static/js/main.XXXXXXX.js.

Normally you want this because it keeps you from mixing assets from multiple releases in the client’s cache. You’ll never have old JS on a new page. When you load your site you hit the main HTML page which then pulls in all the CSS, JS, etc. The browser will often cache this homepage and depending on how your caching headers are set up (or aren’t set up) it may or may not cache the underlying CSS / JS assets.

So imagine we reploy, we make a new homepage which is now looking for new randomly-generated cache-breaking filenames. If you go to your site and refresh, your browser may be caching the homepage. If it serves up the cached homepage from the previous release then none of the assets it wants will exist anymore because the randomly generated filenames no longer exist because your latest deploy removed them.

So how does this surface to you? Well, we get this crazy error because <script src="./non-existant-script.js"></script> will resolve to a 404 page, specifically a 404 page written in HTML where the first character is <. If you try to evaluate HTML as JS, you get an unexpected token error.

To work around this you can work on the cache headers for your homepage and ensure that the browser aggressively refreshes it, you can disable the cache-breaking filenames (which is easy but might result in mixing versions), or you can ignore it because it only happens if you’ve recently cached the old homepage and most users wont hit that.

Personally, if I don’t want any error, then I’d disable all caching on the homepage. You can specify the headers in firebase.json (docs) and here’s a Stackoverflow post about disabling caching with HTTP headers.

If you do this, it will be more expensive and slower because the client will fetch the page on each release, however the actual HTML page is very small, so it probably wont make a big difference. The assets, which are the big part, will still cache normally.

Freshness vs. speed is always a trade-off and it depends on your use-case, release cycle, and tolerance for different issues.

hi guys, i’m facing the same issue, and it’s actually common if you front end is a single page application with lazy resource load when open a new route. Ths issue is caused when a new version of firebase hosting is deployed, it might have wiped out all the resources serving from the previous version (even if they have different names).

so when a user who has their front end page open before the deployment, when they continue their browsing after the deployment without a page refresh, when they navigate to a different route with resource that has not been loaded before, their existing page resource loader will try to load the assets from the previous version, which cause firebase return a 404 html page for the resources, and therefore causing the error.

@abeisgoat is there anyway we can keep like just the previous release version on the hosting?

[REDACTED]