Open jimafisk opened 1 month ago
In my initial testing I was running into parent_component is null
errors: https://github.com/sveltejs/svelte/issues/6584
After doing several cache clears ctrl-f5 and using incognito/private browsing windows, it appears to work as expected and I can't recreate the error. If folks do run into this however, please let me know!
I attempted to load the fingerprint only when replacing the import path (https://github.com/plentico/plenti/commit/1005ca658a16e1aaaa3ee67a79dcd9f64fed5099). This resulted in a different fingerprint for each import. This was not my intention, but I didn't think this would be a problem, but it kept throwing the parent_component is null
(firefox) / Cannot read property '$$' of null
(chrome/brave) errors. I'm still not entirely sure why that is, maybe has something to do with imports from different files referencing the same component (still not sure why that would matter), but reverting for now seems to fix the issue. I'm somewhat worried because I saw this behavior even when passing the same fingerprint
throughout gopack, although I can't recreate that now.
I can't seem to avoid the parent_component is null
(firefox) / Cannot read property '$$' of null
(chrome/brave) errors from periodically happening when trying to individual fingerprint each file. I'm going to revert these changes for now until we can figure out a better solution.
I found a good way to replicate the issue with the hashed folder in case folks want to test:
We recently updated our cache busting strategy to use query params: https://github.com/plentico/plenti/issues/315
My hope was that breaking the entrypoint would have a cascade effort to breaking other cached files referenced downstream. I thought this was working based on initial tests, but that does not seem to be the case now that I've used it more extensively.
It puts us in a hard place, breaking the cache using a folder runs the risk of inactive Chrome tabs not correctly fetching the assets when reactivating, and only breaking the entrypoint runs the risk of serving up stale content already cached. I think we're going to have to ultimately fingerprint (with query string) every file in the SPA. We should be able to do this using gopack, since we're already rewriting every import to resolve to a valid ESM path during the build.