Parcel: 🙋 PWA support

[Olian04]

_This is both a question and a :raising_hand_woman: feature request._

__Question:__

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 https://github.com/parcel-bundler/parcel/issues/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.

[Olian04]

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) {
    navigator.serviceWorker.register('./service-worker.js')
        .then(function(registration) {
            console.log('Registration successful, scope is:', registration.scope);
        })
        .catch(function(error) {
            console.log('Service worker registration failed, error:', error);
        });
}

[kennetpostigo]

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.

[Olian04]

@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?

[kennetpostigo]

@Olian04 well seeing as it knows the assets a site uses, it could cache assets for us automagically.

[Olian04]

@kennetpostigo Yes that is true, however caching responses is only one part of a service worker. And since we can't register multiple service workers for the same site the caching should probably be left to the programmer.

[kennetpostigo]

@Olian04 sure, but at the very least, if there is no service worker file present for this, parcel could fallback to generating a basic one for you to cache assets at the very least.

Some plugins parcel might take inspiration from and "turn on by default" when parcel detects you don't have a dedicated serviceworker could be:

• https://github.com/NekR/offline-plugin
• https://github.com/goldhand/sw-precache-webpack-plugin

[Olian04]

@kennetpostigo at first I was ready to agree with you, since on the surface providing a service worker automatically would just improve performance. However, after reasoning about it I don't actually think we want to automatically force a service worker onto everyone who uses parcel. We have no way of knowing what issues that might cause. On top of that, I don't really think it's parcels place to be injecting code into a prod app. Parcel is first and foremost a bundler, and it isn't really common practice for bundlers to add functionality to the bundle without the users consent. I like the idea of parcel offering a cache only service worker as an option for the dev to opt into though.

[kennetpostigo]

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.

[devongovett]

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!

[mischnic]

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.
  
  

[cyyyu]

I also made a plugin. https://github.com/cyyyu/parcel-plugin-sw-precache 😄

[marcusasplund]

I went the way with workbox cli instead, it seems to work alright for me.
https://github.com/marcusasplund/hyperapp-todo-parcel
I now score 100 pwa with the lighthouse diagnosis tool
BUT when doing a build i still have to manually copy the icon- and manifest tags in the head, and all the icons with proper names from src as parcel rewrites all icon names https://github.com/parcel-bundler/parcel/issues/220 as well as turning the manifest json file into a js file https://github.com/parcel-bundler/parcel/issues/235

[mischnic]

@marcusasplund With the next release, this will be handled automatically.
You only need to rename you manifest to something like manifest.webmanifest.

[marcusasplund]

@mischnic I suppose this commit should take care of the problem, or am i mistaken?
Parcel-bundler v 1.6.2 still produces "scrambled" names for manifest, icons etc

  <link rel="apple-touch-icon" sizes="180x180" href="/dist/1c7c3abdf60685a811043556b00ed1bf.png">
  <link rel="icon" type="image/png" sizes="32x32" href="/dist/e78f1c521d44f72702ec4666af75cbab.png">
  <link rel="icon" type="image/png" sizes="16x16" href="/dist/5d284f8fd4e08e364e1ce496e68e22a2.png">
  <link rel="manifest" href="/dist/54dce0fdf0c5f40eef2cab9e124ae808.webmanifest">
  <link rel="mask-icon" href="/dist/a76e301e687fd68bb19bdfe8f15ff16a.svg" color="#5bbad5">

Is this still expected behavior or have i missed something?

[DeMoorJasper]

@marcusasplund this is expected behaviour currently. There is an open RFC for naming strategy however, feel free to add to that issue :)

872

_{Sent with GitHawk}

[rodoabad]

Hey guys, how are things going with PWA support?

[kidandcat]

I'm interested too, how is it progressing?

[talentlessguy]

Hey, still no PWA? :( Sadly I'll have to move to Rollup instead of Parcel just because of not having PWA suppprt.

[edm00se]

Until there’s further native support by parcel, I settled on creating a script to run after parcel’s build, to generate the service worker from workbox-cli; the manifest file is processed by parcel from src/. It works pretty well and you can see a simple example here.

Edit: not trying to assume too much, since it was a rather leading intro

[talentlessguy]

Until there’s further native support by parcel, I settled on creating a script to run after parcel’s build, to generate the service worker from workbox-cli; the manifest file is processed by parcel from src/. It works pretty well and you can see a simple example here.

My problem is that webmanifest doesn't work properly. I mean, it doesn't work at all. Icons / themes are not set on mobile version.

Here is the repo

And webmanifest:

{
  "name": "V ! R T L",
  "short_name": "V ! R T L",
  "description": "V ! R T L's personal site",
  "theme_color": "#000000",
  "background_color": "#ffffff",
  "display": "standalone",
  "scope": ".",
  "dir": "ltr",
  "lang": "en-US",
  "start_url": "./index.html",
  "icons": [
    {
      "src": "assets/manifest/icon-72x72.png",
      "sizes": "72x72",
      "type": "image/png"
    },
    {
      "src": "assets/manifest/icon-96x96.png",
      "sizes": "96x96",
      "type": "image/png"
    },
    {
      "src": "assets/manifest/icon-128x128.png",
      "sizes": "128x128",
      "type": "image/png"
    },
    {
      "src": "assets/manifest/icon-144x144.png",
      "sizes": "144x144",
      "type": "image/png"
    },
    {
      "src": "assets/manifest/icon-152x152.png",
      "sizes": "152x152",
      "type": "image/png"
    },
    {
      "src": "assets/manifest/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "assets/manifest/icon-384x384.png",
      "sizes": "384x384",
      "type": "image/png"
    },
    {
      "src": "assets/manifest/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "splash_pages": null
}

For reproduce you need to run yarn prepare and then surge dist

[edm00se]

@talentlessguy The link to your web manifest doesn’t resolve for me; also your repo source looks to make use of poi and I don’t see parcel as a dependency in your package.json.

[talentlessguy]

@talentlessguy The link to your web manifest doesn’t resolve for me; also your repo source looks to make use of poi and I don’t see parcel as a dependency in your package.json.

Oh sorry I forgot to attach links to history. Here is the version with Parcel.

[edm00se]

@talentlessguy the only major difference I noticed was in your index.html, the meta tag ref was the raw manifest file name, while mine use the path relative notation, such as <link rel="manifest" href="./manifest.webmanifest">. I haven’t had issues using a web manifest myself since ensuring I had the right file extension.

Here’s my manifest link, if you want to try to play “spot the differences”.

[talentlessguy]

@edm00se it is weird that this works <link rel="manifest" href="./manifest.webmanifest"> but this doesn't <link rel="manifest" href="manifest.webmanifest"> But I'll try to use "raw" paths next time

[devongovett]

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

[talentlessguy]

@devongovett see my comment above, manifest link doesn't work without "raw" path. But I think ./ is fine too.

[edm00se]

What exists today works for me, so with that caveat:

• detect sw.js (or similar) and ignore/warn its lack of file with the expectation of an externally generated file
  
  
  
  • currently this breaks hard as Parcel expects a referenced js file to exist during the registering of the service worker file; not a big surprise there
  
  
  • this would prevent the need to stub a blank file to work around this
  
  

While the lazy developer in me would love to see native support of generating the web manifest or service worker, the plugin space is probably the best realm for that. Neither above plugin worked (immediately) for me when I tried them, so I moved on; this was months ago, so they may be just fine. I generate my service worker from workbox, after the build Parcel completes, which is what's driving my above scenario.

Also, thank you @devongovett.

[mischnic]

detect sw.js (or similar) and ignore/warn its lack of file with the expectation of an externally generated file

Related: https://github.com/parcel-bundler/parcel/issues/2080