Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Issues with Sapper in pinafore.social #242
I promised Rich that I would file some bugs/feature requests after launching https://pinafore.social, but unfortunately I haven't had a lot of time to make reductions/etc., so I'm opening a mega-issue to describe problems I ran into; feel free to ignore or close as you see fit.
First off I should say I'm using a fork of Sapper from early January, so I'm not in a rush to have these issues fixed, since everything Works For Me™. But I thought it'd be worthwhile to at least provide the feedback.
On redirect, you'll see this error:
I suspect the issue has something to do with Webpack 4 and the new
Again, sorry for the mega-issue and for not providing a PR to help out. The work you've put in to Svelte and Sapper are incredible, and the code is readable and comprehensible enough that I'm happy using my January fork for now. Hopefully I'll be able to complete the upgrade soon and offer some PRs to help make it happen.
Thank you! I'll be honest, I was braced for a much longer list than this, so colour me pleasantly surprised.
Route preloading is disabled by default in the most recent version — there's a
And congrats on Pinafore!
Thanks for the feedback! The route priority bug may indeed be fixed. I tested this about a month ago and wrote a workaround in my
The other issue (the Webpack 4 one) is definitely still active, though. I just tested in Sapper 0.9.6 to make sure.
Another issue I ran into recently is with the service worker timestamp.
My solution was to use
An alternative may be to generate a unique hash based on the actual contents of the service worker (which would thus be unchanged across builds). But I opted not to do that, because I have other logic in place to sort the caches by timestamp and keep the last 2, to work around issues where a service worker may delete a webpack asset before the user reloads, which would then break when the user tries to load an async chunk.
I think we can close this issue now as everything can either be considered resolved or has a dedicated issue:
I've opened #415 to track this
Route preloading is disabled by default, as noted above
This has been robustified a lot since then (completely different mechanism) so I'm fairly certain this is fixed
I'm not aware of any similar reports so I'm going to optimistically assume that this was a short-lived bug (bringing the repro up to date with current versions is going to be a little tricky)
Interesting... I don't think we need a separate issue for this, as it can be solved in userland as you demonstrated. I'd be wary of the hash-based solution since it could result in zombie caches (if the service worker itself was unchanged, but assets/generated content had changed).