Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

πŸ™‹ PWA support #301

Closed
Olian04 opened this issue Dec 15, 2017 · 28 comments Β· Fixed by #5700
Closed

πŸ™‹ PWA support #301

Olian04 opened this issue Dec 15, 2017 · 28 comments Β· Fixed by #5700

Comments

@Olian04
Copy link

Olian04 commented Dec 15, 2017

This is both a question and a πŸ™‹β€β™€οΈ 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 #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
Copy link
Author

Olian04 commented Dec 16, 2017

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
Copy link

kennetpostigo commented Dec 16, 2017

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
Copy link
Author

Olian04 commented Dec 17, 2017

@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
Copy link

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

@Olian04
Copy link
Author

Olian04 commented Dec 17, 2017

@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
Copy link

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

@Olian04
Copy link
Author

Olian04 commented Dec 19, 2017

@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
Copy link

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
Copy link
Member

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
Copy link
Member

mischnic commented Jan 22, 2018

I have create a plugin (https:/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
Copy link

cyyyu commented Feb 4, 2018

I also made a plugin. https:/cyyyu/parcel-plugin-sw-precache πŸ˜„

@marcusasplund
Copy link

I went the way with workbox cli instead, it seems to work alright for me.
https:/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 #220 as well as turning the manifest json file into a js file #235

@mischnic
Copy link
Member

mischnic commented Feb 9, 2018

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

@marcusasplund
Copy link

@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
Copy link
Member

DeMoorJasper commented Feb 26, 2018

@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
Copy link

Hey guys, how are things going with PWA support?

@kidandcat
Copy link
Contributor

I'm interested too, how is it progressing?

@talentlessguy
Copy link

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

@edm00se
Copy link

edm00se commented Aug 5, 2019

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
Copy link

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
Copy link

edm00se commented Aug 6, 2019

@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
Copy link

@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
Copy link

edm00se commented Aug 6, 2019

@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
Copy link

@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
Copy link
Member

devongovett commented Aug 12, 2019

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
Copy link

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

@edm00se
Copy link

edm00se commented Aug 12, 2019

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

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
Copy link
Member

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

Related: #2080

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet