Use a Custom Service Worker in a create-react-app PWA without Ejecting

Instructor: [00:00] The most basic way to replace the default service worker is to make a new file in the public folder and we'll call that myserviceworker.js. That name could be anything you'd like, but the file must be in the root of the public folder, so that it can be served from the root of our application.

[00:19] Let's just add a console.log line here. Then open serviceworker.js. There we can find the old service worker file name and replace it with our new service worker file name. Again, it's important that we serve from the root here because the service worker can only control the parts of the app that are at the same level or below the level that it's served from.

[00:44] Then we can make a new production build and serve it and open it in Chrome. In the console tab we can see our "Hello" message, so we know the service worker is running. Also, in the application tab of Chrome's DevTools we can see the new service worker file name. If we click on it we can see our custom service worker.

[01:07] That's the easiest way to replace the service worker, but it totally bypasses Workbox, which has a lot of functionality that we want to take advantage of for this application. Let's revert back to the original file name and delete the custom service worker.

[01:22] In terminal install react-app-rewired, which we can use to rewrite the webpack config without ejecting and take full advantage of Workbox. Make a new file called config-overides.js in the root of the project. We'll copy in the default function from the react-app-rewired's documentation.

[01:44] To see what we're working with, we can log the config here. Then comment out the return, which will help the webpack process and let us see the config. Next open package.json in the root of the project and replace the default react-script-calls with react-app-rewired for start, build, and test.

[02:08] Now let's make a production build, which shows us the config that we're working with, and then stops the build process. The basic service worker is currently being generated by this Generate SW plugin. That's the plugin that we want to replace with a more fully featured Workbox plugin.

[02:27] In config-overides.js we can import Workbox, and then map over all the plugins. When we get to the Generate SW plugin, we'll replace it with InjectManifest from Workbox. We can name the source whatever we'd like. We'll call that sw.js and put it in the source folder. The destination has to match what we have in serviceworker.js. We'll call that service¬-worker.js.

[03:07] Now we can make the new sw.js file in source. Here we can define our custom service worker. As for the console log like before, but we can also use all the power of Workbox. For this example, we'll call Skip Waiting and Client's Claim, which will ensure our service worker gets installed on all the open clients right away.

[03:30] If your service worker is complex you probably don't want these two lines, but they're useful for this demo. Finally, we can build a new build and serve it. Then open a new tab and navigate to it in Chrome. In the console we see our message. Then in the application tab we can see the generated service worker code and we can see that Workbox is properly setup and working.