Yes.
When set PUBLIC_URL to a cdn address, service worker registration is blocked. It seems a cross-domain problem:
Error during service worker registration: DOMException: Failed to register a ServiceWorker: The origin of the provided scriptURL ('https://o0tu0aq0f.qnssl.com') does not match the current origin ('https://apporz.com').
ServiceWorker should work well when PUBLIC_URL isn't local host.
ServiceWorker doesn't work.
npm ls react-scripts (if you haven鈥檛 ejected): [email protected]node -v: v7.10.0npm -v: v4.2.0Then, specify:
See console output on my website.
cc @jeffposnick
We allow people to compile with PUBLIC_URL env variable set to a CDN (for JS and CSS assets).
Should we turn off service worker in this case?
Ah, I wasn't aware of PUBLIC_URL. Skipping the service worker registration would be a good idea in that case, yes.
So... I guess changing this line to:
if (!process.env.PUBLIC_URL && process.env.NODE_ENV === 'production' && 'serviceWorker' in navigator) {
// registration
}
would work? Does PUBLIC_URL get exposed in process.env like that?
Yep, it should be.
AFAIK we always provide process.env.PUBLIC_URL, but by default it's a path not url.
We'd probably need to do /^[.|/]/.test(process.env.PUBLIC_URL)
That makes sense, @Timer. You know those environment variables better than I do, so anything you think along those lines that would detect a different origin would make sense.
(I normally do this sort of thing by constructing URL objects, because they're always available inside a service worker, but I understand that URL might not be supported in all of the browsers you need to target.)
Fixed in 1.0.8. Please verify.
https://github.com/facebookincubator/create-react-app/releases/tag/v1.0.8
(you'll need to follow migration instructions since this change won't be migrated to your project automatically)
All things work well, thank you all.
Why not also use service worker when PUBLIC_URL env variable set to a CDN?
We can serve index.html and service-worker.js in our server(the same origin) and put other js/css/images assets into our CDN server. And then using service worker to cache assets in CDN server.
i agree with @VincentBel
i want to serve js/css/images from CDN and still want to precache them..
currently i has problem with service worker after setup PUBLIC_URL to my cdn server
lets say that i has
domain.com
cdn.domain.com/main.js
the precached files are
domain.com/index.html
domain.com/main.js
domain.com/main.css
and there are lines like this in generated service worker.js
urlsToCacheKeys.has(n));!t&&"navigate"===e.request.mode&&isPathWhitelisted(["^(?!\\/__|\\/admin\\/|\\/api\\/).*"],e.request.url)&&(n=new URL("https://cdn.domain.com/index.html"
the results are
cdn.domain.com/main.js@hartono-sulaiman-kaskus, what you describe is expected after https://github.com/facebookincubator/create-react-app/pull/2432 went into effect.
The history behind that PR can be found upthread. There are definitely scenarios in which you can configure everything properly to safely use a service worker while retrieving all of your assets from a CDN, but doing so requires a lot of assumptions (such as: your CDN supports CORS, that the deployment of your service-worker.js and CDN happens at exactly the same time, etc.). It's not safe to make those assumptions in a general-purpose project like create-react-app.
(If you want to manually update your service worker configuration, post-eject, because you know that the way you're using a CDN is "safe" from the issues I mentioned above, then the stripPrefixMulti option allows you to remap the precached URLs.)
Most helpful comment
Why not also use service worker when
PUBLIC_URLenv variable set to a CDN?We can serve
index.htmlandservice-worker.jsin our server(the same origin) and put other js/css/images assets into our CDN server. And then using service worker to cache assets in CDN server.