🙋 PWA support

This is both a question and a 🙋‍♀️ feature request.


Since a PWA requires a set of resources to exists along side its manifest.webmanifest file. My question is, is there a way to include a file without having its name “scrambled”? This would apply to both the manifest file and its resources. (Related to #280)

Feature request:

It would be nice to have parcel look through the manifest file for files to include in the build.
For example (partial files):

<!-- index.html -->
<link rel="manifest" href="./manifest.webmanifest">
// manifest.webmanifest
"icons": [{
      "src": "pwa/icons/48.png",
      "sizes": "48x48",
      "type": "image/png"
    }, {
      "src": "pwa/icons/72.png",
      "sizes": "72x72",
      "type": "image/png"

Should result in both manifest.webmanifest as well as pwa/icons/48.png and pwa/icons/72.png being included in the build.

15 thoughts on “🙋 PWA support

  1. The name “scrambling” is a problem when working with service workers as well.
    Especially since service workers has to be their own files.

    if ('serviceWorker' in navigator) {
            .then(function(registration) {
                console.log('Registration successful, scope is:', registration.scope);
            .catch(function(error) {
                console.log('Service worker registration failed, error:', error);
  2. Given the control and information parcel has about the app it’s working on, might be the perfect opportunity for parcel to generate a service worker for us. IMO, it would be an opinionated feature to add but one that would be great. All apps could benefit from using a serviceworker. Parcel just happens to have the perfect opportunity to generate one.

  3. @kennetpostigo When you say generate a service worker what part of using a service worker do you suggest parcel should generate? IMO a service worker is a script like any other, so its contents couldn’t/shouldn’t be generate. And the registration of a service worker is a js event (as seen in my previous comment) witch will have to be “subscribable” by the programmer, so this couldn’t/shouldn’t be generate either. So what part exactly are you suggesting parcel to generate?

  4. It could be opt-in --with-sw, or just --no-sw. I guess it may not be parcels place, but sure would be handy in many cases.

  5. As of #398, parcel detects calls to navigator.serviceWorker.register and processes the dependency. Generating a basic service worker automatically sounds like a good plugin to me!

  6. I have create a plugin (https://github.com/mischnic/parcel-plugin-sw-cache) which should act similiar to the sw-precache webpack plugin (although using the still in development successor workbox). But I ran into a few ‘architectural’ problems:

    • For precaching to work the plugin has to run when the bundle is already created because it need to know the files to cache (obviously). That means however that navigator.serviceWorker.register in a JS file doesn’t work, because the service worker isn’t yet created during bundling. That means I had to resort to put the loading code into the html file to circumvent parcel’s bundling.
    • Because the build folder is part of the URL (instead of using the build folder as the web root and putting the bundled files into a folder called something like static) a workaround is needed to correctly load the service worker:
      • If the build folder couldn’t be changed navigator.serviceWorker.register('/dist/sw.js') could be used to install the service worker. But if it isn’t dist this wouldn’t work at all (rewriting the html file seems overly complicated). The same applies to production.
  7. For those of you asking for “PWA support”, what are you referring to exactly? We already support webmanifest files, and there are various plugins in this thread that will generate a service worker for you if you don’t want to write it yourself. So, what else are you looking for Parcel to do for you?

    cc @rodoabad @kidandcat @talentlessguy @edm00se