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

[grrrian]

[REQUIRED] Environment info

*firebase-tools: 6.10.0

Platform: Ubuntu (Bitbucket Pipelines running Node 9.5.0)

[REQUIRED] Test case

When visiting a deployed website, I get a blank page with the console error: Uncaught SyntaxError: Unexpected token <. Refreshing the webpage fixes it!

[REQUIRED] Steps to reproduce

1. Deploy you website
2. Visit it on Chrome
3. Close you browser tab
4. Deploy a new version
5. Visit it on Chrome
6. See a blank page with the above error :(

[REQUIRED] Expected behavior

See your website!

[REQUIRED] Actual behavior

See a blank page with the above error :(

Note: Refreshing the page fixes the issue!

[google-oss-bot]

This issue does not have all the information required by the template. Looks like you forgot to fill out some sections. Please update the issue with more information.

[abeisgoat]

Please fill out the template when opening a bug.

[abeisgoat]

Thanks for filling out the template.

[abeisgoat]

This is likely an issue in your code, Firebase Hosting ships your code verbatim to our CDN, so it's very unlikely that this is an issue on our end. Can you provide a link to a page where you're seeing this so I can take a look?

[grrrian]

[REDACTED]

[grrrian]

I'm wondering if it has something to do with the way Chrome caches websites, because it only happens after i visit a website that i re-deployed. And refreshing fixes the issue :(

[grrrian]

I could re-deploy it to allow you to test it.

[abeisgoat]

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.

[grrrian]

Thanks a lot! How would you recommend creating cache headers to force refreshes?

[grrrian]

Perhaps i'll try this:

<meta http-equiv=“Pragma” content=”no-cache”>
<meta http-equiv=“Expires” content=”-1″>
<meta http-equiv=“CACHE-CONTROL” content=”NO-CACHE”>

[abeisgoat]

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.

[grrrian]

Sweet, thanks a bunch @abeisgoat !