Custom ServiceWorker config

[huygn]

1.0.0 added Progressive Web App support, is it possible to support custom config in near future? I really don't want to eject just to add runtime caching configs 😄

[Timer]

What specifically would you like to be able to change?

[huygn]

Currently I use sw-precache with a config file and run sw-precache --config=sw-precache-config.js after the build script.

I would expect to be able to define a sw-precache-config.js (or anything) to define my own configs.

[Timer]

@gnhuy91 so we are most likely not going to let you define your own config, but if you let us know what you are trying to achieve, we can consider adding support for specific options.

[huygn]

Thanks, this is my current config:

module.exports = {
  swFilePath: 'build/service-worker.js',
  stripPrefix: 'build/',
  staticFileGlobs: [
    'build/*.html',
    'build/manifest.json',
    'build/static/**/!(*map*)',
  ],
  dontCacheBustUrlsMatching: /\.\w{8}\./,
  navigateFallback: 'index.html',
  runtimeCaching: [{
    urlPattern: /https?:\/\/fonts.+/,
    handler: 'fastest',
  }, {
    urlPattern: /https?:\/\/images.+/,
    handler: 'fastest',
  }],
};

Currently I only need to define some runtimeCaching for my app, further configs may arise but I think most people will mostly find runtimeCaching useful and want to make use of it.

[dsgh]

@Timer I just updated to the newest version, and tried to use the new PWA support as well, and there seems to be an issue with Firebase auth. Firebase auth uses the /__/auth/handler path, which seems to be 'cached' by the default config (returning the app itself). So for now I had to abandon the idea. Here's what I believe to be a related issue, for the polymer project: https://github.com/Polymer/polymer-build/issues/35#issuecomment-245981301

[gaearon]

cc @jeffposnick on suggestions for how a tool striving to have minimal configuration could handle this.

[jeffposnick]

There are definitely use cases where folks might want something other than the default configuration. I tried to choose default configuration options that are, in general safe, with the understanding that developers who need to make changes will go through the eject flow and modify the configuration (which seemed to in keeping with the overall approach for this project).

I don't know how common it is for servers to use the /__ prefix for "special" URLs that are server-rendered and shouldn't be fulfilled via the locally cached content, but adding in the configuration option

{
  navigateFallbackWhitelist: [/^(?!\/__)/]
}

would account for them. Doing so would be unlikely to break anyone, and it would accommodate some of the folks upthread without forcing them to eject.

As for the questions about configuring runtimeCaching, I tried to cover that in item 7 of this guide. There's no single configuration option that's likely to work for everyone, so using the eject flow would be the way forward.

[sanfilippopablo]

I was really tempted to come here to support being able to configure runtimeCaching, but I think @jeffposnick is right. I think eject is the way to do for this.

[addyosmani]

I'm going to have to agree with Jeff that for now ejecting is probably the best call for customizing runtimeCaching. There are a few too many permutations for how we've seen folks use the option to provide a flexible alternative that would be as useful.

[gaearon]

I’ll close this for now, as we’re not going to do it soon, but we might consider this at some point in the future. For now you’d either need to eject, or add your own custom build step react-scripts build. Thanks for feedback!

[dsgh]

Just for reference, here's how I've implemented the extra build step for the app to work with firebase auth:

const fs = require('fs')
fs.readFile('build/service-worker.js', 'utf8', (error, data) => {
  if (error) {
    return console.log(error)
  }
  const result = data.replace(/isPathWhitelisted\(\[\]/g, 'isPathWhitelisted([/^(?!\\/__)/]')
  fs.writeFile('build/service-worker.js', result, 'utf8', (error) => {
    if (error) {
      return console.log(error)
    }
  })
})

EDIT: This is not needed now, see below.

[ryansully]

I've discovered that the issue that @dsgh mentioned is present in other projects such as https://github.com/Polymer/polymer-cli/issues/290, and the default navigateFallback configuration in Webpack config clobbers any Firebase project that uses auth or any other feature that makes use of Firebase's reserved namespace (/__*) (according to https://firebase.google.com/docs/hosting/reserved-urls, there are a few uses of the reserved namespace). So far, the only solution for that case is @jeffposnick's navigateFallbackWhitelist config, so as long as navigateFallback is set by default in Webpack config, then I think the whitelist should also be set by default.