Fix remaining chunk error noise
I've been getting more Sentry errors about JS chunk errors after deploys, and finally looked into it!
Turns out that, our try/catch handling was working great, and the page was reloading correctly for users as expected. But in these scenarios we would _also_ throw and log two uncaught errors!
The first is that, because we're a single-page app, unrecognized routes fall back to the index.html by default (to power our custom client-side routes, like /outfits/123 etc). So this meant that missing JS files, which _should_ be returning a 404, were instead returning 200 OK and an HTML file, which failed to parse. (And running the script isn't included in the catchable part of the `import` promise!)
Now, in our `vercel.json` config, we catch those paths specifically and 404 them. (The exact choice of path is important: on dev, all these routes run _before_ the dev server, which is responsible for serving the static files - but dev doesn't include hashes in the JS file names, so this 404 route only matches built prod JS files, not local dev JS files.)
The second is that we failed to return anything to `@loadable/component` in the error case, so it would try to render `undefined` as if it were a component class. Now, we return a trivial component class that returns null!
2021-01-26 11:43:27 -08:00
|
|
|
{
|
|
|
|
|
"routes": [
|
2021-05-20 20:35:41 -07:00
|
|
|
{
|
|
|
|
|
"src": "/outfits/(?<id>[^/]+)/v/(?<updatedAt>[^/]+)/(?<size>150|300|600).png",
|
|
|
|
|
"dest": "/api/outfitImage.js?size=$size&id=$id&updatedAt=$updatedAt"
|
|
|
|
|
},
|
Don't handle /outfits/new with SSR
Right, the routes are a bit confusing, `/outfits/new` matches `/outfits/:id`, but shouldn't.
I fix this at the routing level, by creating a more specific `/outfits/new` route that matches first, and just serves `index.html` right from the CDN.
To check that it's exact, I check for either a `?` or the end-of-string after `new`. That way, `/outfits/newish` correctly redirects to the SSR. (This doesn't actually matter a lot, because outfit IDs are only ever numbers and therefore can't start with "new"? But I figure, better to have an unambiguous semantic, then leave random things relying on outfit ID format assumptions.)
2021-05-14 20:35:24 -07:00
|
|
|
{ "src": "/outfits/new(\\?|$)", "dest": "/index.html" },
|
2021-05-20 20:35:41 -07:00
|
|
|
{ "src": "/outfits/(?<id>[^/]+)", "dest": "/api/outfitPageSSR.js?id=$id" },
|
Fix remaining chunk error noise
I've been getting more Sentry errors about JS chunk errors after deploys, and finally looked into it!
Turns out that, our try/catch handling was working great, and the page was reloading correctly for users as expected. But in these scenarios we would _also_ throw and log two uncaught errors!
The first is that, because we're a single-page app, unrecognized routes fall back to the index.html by default (to power our custom client-side routes, like /outfits/123 etc). So this meant that missing JS files, which _should_ be returning a 404, were instead returning 200 OK and an HTML file, which failed to parse. (And running the script isn't included in the catchable part of the `import` promise!)
Now, in our `vercel.json` config, we catch those paths specifically and 404 them. (The exact choice of path is important: on dev, all these routes run _before_ the dev server, which is responsible for serving the static files - but dev doesn't include hashes in the JS file names, so this 404 route only matches built prod JS files, not local dev JS files.)
The second is that we failed to return anything to `@loadable/component` in the error case, so it would try to render `undefined` as if it were a component class. Now, we return a trivial component class that returns null!
2021-01-26 11:43:27 -08:00
|
|
|
{
|
|
|
|
|
"handle": "filesystem"
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"src": "/static/js/[^.]*\\.[^.]*\\.chunk.js",
|
|
|
|
|
"status": 404
|
|
|
|
|
}
|
|
|
|
|
]
|
|
|
|
|
}
|