Someone pointed out that we don't have anything that uses Webpack listed under https://workboxjs.org/examples/#projects-using-workbox

@prateekbh, would you consider https://github.com/prateekbh/Guess to be a representative example that follows the best practices? If so, could you update it to use the latest workbox-webpack-plugin and then we'll link to it?

A rundown of some of my tasks related to getting examples on the site, roughly in the order in which I plan on tackling them.

• Create _layout and supporting _includes for each example to inherit from.
• Standard way of displaying source code for SW and page's JS on each page, without needing to open DevTools.
• Update the landing page for examples so that it includes an auto-generated list of all the available examples in the repo, as well as a curated list of standalone examples that live elsewhere.
• Create smaller, standalone usage examples for each module.
• Create a larger, "full" demo that shows everything used together harmoniously, as part of workbox-sw.
• Hook into publishing process, ensuring that each example lives in a versioned parent directory, and pulls in the appropriate version of the module it needs.
• Standard way of visualizing SW state (registration/control, cache state, logs) on each page, without needing to open DevTools.

Approved:

• Forbes
• iHeartRadio

I'm not including this in #7, as it's going to have to be prioritized lower than that work. But I wanted to keep track of the need to create automated, end-to-end tests for each of the examples.

and give me access, plz

Hello,

When I generate sw with cli: workbox-cli generate:sw, sw created automatically. Its good. But at bower_components directory there are a lot of unnecessary codes (in html etc.) I wonder, is it possible to collect file list only necessary at web app loading. Beside, I load sw in app page after first paint completed (in lazy loading documents.) at devtool/Application tab, seams sw registered. But when I check the app with Audits (lighthouse). says unlucky no service worker. Either I moved the code to index html , it is the same. ( the list at sw too long !) (you can see the live site jobijoy.com )

When I navigate to: Workbox overview page and I click on the injectManifest() link above the Feedback section it navigates to a 404 page.

As we link to one from the homepage.

Low contrast is hard to read. Gray on gray is never high contrast. At the very least, the sample code should be white or indistinguishably close.

The components at https://github.com/GoogleChrome/howto-components are much nicer than what we're using right now for /examples.

CC: @surma to confirm that they're ready to be used.

GoogleChrome/workbox#757

In DevSite, I can just use the following syntax to define an explicit anchor for each section:

## Name of section {: #name }

And then you link to that section via https://example.com/page#name.

Jekyll just auto-generates section anchors from the text, which often creates really ugly and long anchors. Also, if you change the text, the anchor fragment is no longer valid. This is a big problem for me, because I do change the text often, and I often link directly to sections for maximum usability

https://workboxjs.org/overview.html

I've followed https://demisx.github.io/gulp4/2015/01/15/install-gulp4.html and see

$ gulp -v
[17:28:15] CLI version 1.3.0
[17:28:15] Local version 4.0.0-alpha.2

When I run gulp build, I get:

$ gulp build
module.js:487
    throw err;
    ^

Error: Cannot find module 'yargs'
    at Function.Module._resolveFilename (module.js:485:15)
    at Function.Module._load (module.js:437:25)
    at Module.require (module.js:513:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/Users/jeffy/git/workbox-microsite/node_modules/gulp/node_modules/gulp-cli/index.js:7:13)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)

I think yargs is just being used internally by gulp, so I'm not sure why the dependency isn't getting picked up. I'll investigate further, but wanted to get the details down in case anyone else has ideas.

Hey!

Thanks for your work on workbox! I'm just attempting to get up and running and, whilst the site looks really inviting, there doesn't appear to be much in the way of webpack examples.

I'm one of the maintainers of ts-loader and I'm trying to get up and running with workbox with webpack. It's not clear to me from the docs how that all fits together. Things I am pondering:

I don't know where this belongs:

if ('serviceWorker' in navigator) {

That is to say; I know I need to register a service worker but I'm not too clear where that fits in with webpack. Do I include that code in my entry file? Or is this something I should be putting in a script tag in my app template; i.e. OUTSIDE my application code?

For context I'm writing a super simple react app; a SPA. For the code I'm hoping to amend see here: https://github.com/johnnyreilly/reactspike

It feels the docs should say something about this but don't. It would also be nice to see a webpack / workbox example in the docs. FWIW I have found this: https://github.com/insin/react-hn However, it's not a specifically webpack example. More nwb with webpack....

Thanks again for all you do!

As we link to one from the homepage.

Here is a list of top five priorities in priority oder with links to tracking bugs for each.

• Migration guide.
• Item
• Item

can this apply to WordPress? if yes how can I apply this?

Here's my first take at a rethink of the landing page content after our meeting:

Focus less on the text (we can easily change that). I'd like to figure out if folks feel a layout like this or one like it would be more useful than what we have now.

We could easily expand the later sections to include more features/breakdowns. I kind of love how clean the http://babeljs.io/ site is and tried to draw some inspiration from it.

Shared the Sketch file for my silly attempt with @gauntface

Hi,

I've been reading and re-reading this part of the docs and I'm a little confused:

1. Create a configuration file telling Workbox which resources to cache.
2. Run one of the Workbox tools in your project directory before each deploy. Workbox generates the service worker code needed for caching and updating the resources.

There doesn't seem to be reference anywhere else in the docs as to what this config file is and how to create it. Or perhaps there is and I'm just being a bit dim. (Entirely possible!)

Either way, it might be good to be a little more explicit here in the docs as to what you mean. Perhaps a link how you could create this config file?

Also, am I right in thinking that, if said config file exists, workbox will just pick it up and use it by convention? It looks for a file with a particular name and if it finds it, it uses it?

In case it's relevant I'm using the webpack plugin to generate my service worker and I'm looking with interest at this talk of a configuration file, imagining it might allow me to have more control over the strategies I might want to use.

Thanks for all your work! I really like the potential workbox has to make PWAs more straightforward. I'm open to submitting docs PRs if that's helpful BTW?

We should find a place to link to https://developers.google.com/web/ilt/pwa/lab-workbox, or otherwise incorporate the material into the docs site.

https://workboxjs.org/get-started/webpack
https://workboxjs.org/get-started/gulp
https://workboxjs.org/get-started/npm-script

https://calendar.google.com/calendar/embed?src=gsmnmr45i797q67dfhp08t48no%40group.calendar.google.com&ctz=America/New_York

The source that produced this is here.

As we link to one from the homepage.

@gauntface, do we need gems: ['jekyll-github-metadata'] in our _config.yml? If not, I'll remove it. It leads to failed metadata requests like the following after a few rebuilds:

GitHub Metadata: GET https://api.github.com/repos/GoogleChrome/workbox-microsite: 403 - API rate limit exceeded for 108.46.224.107. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.) // See: https://developer.github.com/v3/#rate-limiting

I just had a bad experience during my first attempt at running npm run deploy locally, and I wanted to document the errors first, and then think about how we can change the deployment pipeline to prevent it from happening again.

Here's what I was seeing:

jeffy [~/git/workbox-microsite]$ npm run deploy

> [email protected] deploy /Users/jeffy/git/workbox-microsite
> npm run test && firebase deploy


> [email protected] test /Users/jeffy/git/workbox-microsite
> npm run lint && gulp build && mocha ./test/node/**/*.js


> [email protected] lint /Users/jeffy/git/workbox-microsite
> eslint '.'

[13:17:25] Using gulpfile ~/git/workbox-microsite/gulpfile.js
[13:17:25] Starting 'build'...
[13:17:25] Starting 'clean'...
[13:17:25] Finished 'clean' after 302 ms
[13:17:25] Starting 'ref-docs'...


      If you want to build the latest refernce docs
      please run serve with the "--code" flag, passing
      in the path to the workbox repo.

          gulp serve --code ../workbox/

      
    Skipping build reference docs for v0.0.1
    Skipping build reference docs for v0.0.2
    Skipping build reference docs for v0.0.3
    Skipping build reference docs for v1.0.0
    Skipping build reference docs for v1.0.1
    Skipping build reference docs for v1.1.0
    Building reference docs for v1.2.0
    Downloading tagged release: v1.2.0
Cloning into '/Users/jeffy/git/workbox-microsite/tmp-1501521444992/v1.2.0'...
warning: redirecting to https://github.com/GoogleChrome/workbox.git/
remote: Counting objects: 450, done.
remote: Compressing objects: 100% (388/388), done.
remote: Total 450 (delta 84), reused 153 (delta 34), pack-reused 0
Receiving objects: 100% (450/450), 330.85 KiB | 0 bytes/s, done.
Resolving deltas: 100% (84/84), done.
Note: checking out 'ccd7c159eb5098e4296df6f3ce18298d9ecc011e'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

    Building JSDocs @ '/Users/jeffy/git/workbox-microsite/tmp-1501521444992/v1.2.0'. Version: v1.2.0
        JSDoc path: /Users/jeffy/git/workbox-microsite/node_modules/.bin/jsdoc
        JSDoc params: [
  "-c",
  "/Users/jeffy/git/workbox-microsite/jsdoc.conf",
  "--template",
  "/Users/jeffy/git/workbox-microsite/src/themes/_jsdoc",
  "-d",
  "/Users/jeffy/git/workbox-microsite/src/reference-docs/v1.2.0"
]
[13:17:28] Finished 'ref-docs' after 2.43 s
[13:17:28] Starting 'jekyll:build'...
[13:17:28] Starting 'npm-dependencies'...
[13:17:28] Starting 'clean-third-party'...
[13:17:28] Finished 'clean-third-party' after 1.05 ms
[13:17:28] Starting '<anonymous>'...
[13:17:28] Finished '<anonymous>' after 29 ms
[13:17:28] Finished 'npm-dependencies' after 30 ms
[13:17:28] Starting '<anonymous>'...
WARN: Unresolved specs during Gem::Specification.reset:
      listen (< 3.1, ~> 3.0)
      rb-fsevent (>= 0.9.4, ~> 0.9)
      rb-inotify (>= 0.9.7, ~> 0.9)
WARN: Clearing out unresolved specs.
Please report a bug if this causes problems.
/Users/jeffy/homebrew/lib/ruby/gems/2.4.0/gems/bundler-1.14.6/lib/bundler/spec_set.rb:87:in `block in materialize': Could not find sass-listen-3.0.7 in any of the sources (Bundler::GemNotFound)
        from /Users/jeffy/homebrew/lib/ruby/gems/2.4.0/gems/bundler-1.14.6/lib/bundler/spec_set.rb:80:in `map!'
        from /Users/jeffy/homebrew/lib/ruby/gems/2.4.0/gems/bundler-1.14.6/lib/bundler/spec_set.rb:80:in `materialize'
        from /Users/jeffy/homebrew/lib/ruby/gems/2.4.0/gems/bundler-1.14.6/lib/bundler/definition.rb:176:in `specs'
        from /Users/jeffy/homebrew/lib/ruby/gems/2.4.0/gems/bundler-1.14.6/lib/bundler/definition.rb:235:in `specs_for'
        from /Users/jeffy/homebrew/lib/ruby/gems/2.4.0/gems/bundler-1.14.6/lib/bundler/definition.rb:224:in `requested_specs'
        from /Users/jeffy/homebrew/lib/ruby/gems/2.4.0/gems/bundler-1.14.6/lib/bundler/runtime.rb:118:in `block in definition_method'
        from /Users/jeffy/homebrew/lib/ruby/gems/2.4.0/gems/bundler-1.14.6/lib/bundler/runtime.rb:19:in `setup'
        from /Users/jeffy/homebrew/lib/ruby/gems/2.4.0/gems/bundler-1.14.6/lib/bundler.rb:100:in `setup'
        from /Users/jeffy/homebrew/lib/ruby/gems/2.4.0/gems/jekyll-3.4.5/lib/jekyll/plugin_manager.rb:36:in `require_from_bundler'
        from /Users/jeffy/homebrew/lib/ruby/gems/2.4.0/gems/jekyll-3.4.5/exe/jekyll:9:in `<top (required)>'
        from /Users/jeffy/homebrew/bin/jekyll:22:in `load'
        from /Users/jeffy/homebrew/bin/jekyll:22:in `<main>'
[13:17:29] Finished '<anonymous>' after 1.38 s
[13:17:29] Finished 'jekyll:build' after 1.41 s
[13:17:29] Starting 'styles'...
[13:17:29] Starting 'html'...
[13:17:29] Starting 'images'...
[13:17:29] Starting 'scripts'...
[13:17:29] Starting 'extras'...
[13:17:29] Starting 'images:copy'...
[13:17:29] Starting 'images:minified'...
[13:17:29] gulp-imagemin: Minified 0 images
[13:17:29] Finished 'html' after 243 ms
[13:17:29] Finished 'scripts' after 243 ms
[13:17:29] Finished 'extras' after 244 ms
[13:17:29] Finished 'images:copy' after 12 ms
[13:17:29] Finished 'styles' after 246 ms
[13:17:29] Finished 'images:minified' after 13 ms
[13:17:29] Finished 'images' after 246 ms
[13:17:29] Starting 'sw'...
[13:17:29] Finished 'sw' after 14 ms
[13:17:29] Finished 'build' after 4.4 s


  Check for Broken Links
    ✓ should have no broken links (55ms)


  1 passing (84ms)


=== Deploying to 'workbox-bab1f'...

i  deploying hosting
i  hosting: preparing build-prod directory for upload...
⚠  Warning: Public directory does not contain index.html
✔  hosting: 2 files uploaded successfully
i  starting release process (may take several minutes)...

✔  Deploy complete!

I'm assuming that the build failed due to that

Could not find sass-listen-3.0.7 in any of the sources (Bundler::GemNotFound)

error. Ideally, a failure in that step of the build pipeline should be treated as a fatal error, and stopping the chain. Failing that, the Firebase deploy step ideally would have treated the

⚠  Warning: Public directory does not contain index.html

as a fatal condition, and also refused to deploy.

Very early stages at https://workbox-samples.glitch.me/

As discussed today, let's work on a plan for how we're going to refresh the site at workboxjs.org for the V3 launch. It would be great to include more examples, be more beginner friendly and ease navigation.

Happy to take a quick looksie too.

As a design choice this looks pretty, but for someone with less than perfect eyes, it's less than ideal to read.

This is one instance where the text doesn't need to align.

We went with the decision that the non-.html version of our URLs would be authoritative, and have a HTTP 301 redirect from .html to non-.html enforced by our Firebase config: https://github.com/GoogleChrome/workbox-microsite/blob/master/firebase.json#L4

There are a couple of things we could improve about the site to account for this:

• We're using the .html version of the URL in our <link rel="canonical" href="/reference-docs/latest/module-workbox-background-sync.html"> tags.
• We're linking to the .html versions of the docs pages from within the "Reference" drop down.
• Our precache manifest has the .html versions of URLs. That means that only requests made for the .html flavor of the URL will work offline. (We can work around this by using templatedUrls to establish a mapping whose keys were the URL without .html, and whose values were the underlying files with .html.)

Or.... we could just turn off the setting in the Firebase config that enables the non-.html 301 redirects, and not really have to change anything else.

I'm just learning about how to manage cached assets and one thing that I found is that I've got pretty good eyesight but I'm struggling to read the text.

1. The body color is too light and doesn't contrast well with the white background. Darken the body font.
2. The body font is too thin.
3. The italic orange text is too thin and doesn't contrast well. On https://workboxjs.org/reference-docs/latest/module-workbox-build.html#.injectManifest the property names in the parameter description.

@addyosmani @jeffposnick @philipwalton @deanhume @jescalan @prateekbh @kaycebasques

This is a bit of a brain dump of things we should do to the Workbox Microsite.

Move to WebFundamentals

• Move build process for ref-docs to WebFundamentals (Started by @gauntface)
• Move existing content over to WebFundamentals
• Move demos to glitch and link up in WebFundamentals (Started by @jeffposnick)

Information Architecture

This is just an idea to try and organise things a little.

- Guides
    - Get Started
    - Compared to sw-<toolbox|precache>
    - How to Configure Workbox
    - How to Precache
    - How to Use Routing
    - How to Handle CORS
    - How to use Plugins
    - How to Enable Offline Analytics
    - Common Recipes for Workbox
    - How to Troubleshoot / Debug
    - How to Migrate from sw-<toolbox|precache>
    - How to Rollup Your Own Build
- Modules
    - Service Worker
        - Loader
        - Precaching
        - Routing
        - Google Analytics
        - Strategies
        - Background Sync
    - Plugins
        - Broadcast Cache Update
        - Cachable Response
        - Cache Expiration
    - Node
        - Build in Node
        - CLI
        - WebPack Plugin

Home Page

• Create a video for the home page covering high-level explanation and use of workbox.
• Highlight some of the common "How to Guides" from the new IA
  • Cache Google Fonts (Inlined in the home page or just linked to?)
  • Cache JS, CSS and Images (Inlined in the home page or just linked to?)
• Call out browser support
• Call out sites using Workbox
  • Forbes
  • Add a "Built by the team that worked on sw-toolbox and sw-precache, as used by Lyft, Washington Post.....(+ others)"
• Inline a demo running on Glitch
  • Could be a set of images with diff caching strategies.
  • Show off the broadcast cache update message
  • Show off service worker templating.
  • Get developer to change precache revision and show only that asset updates?

Reference Docs

• Build out reference docs as Markdown files rather than a file with YAML with HTML as content
  (Should encourage contributions).
• Build Reference Docs into a location that means a module can have normal markdown content next to the actual reference docs.
• Optional Add ability to select a specific version of the docs from available versions.

Footer

This is some stuff we should call out a little better.

- Community
    - Stack Overflow
    - Slack
    - Contributing
- More
    - Blog
    - Github
    - Demos and Examples

Examples > workbox-sw doesn't work on Safari but the demo is not obvious that it doesn't work.

No clue why you are hiding it, you've links to the heads so the user can auto jump to the correct instance method documentation....

Background: I was cursing you all for not documenting https://workboxjs.org/reference-docs/latest/module-workbox-build.html#.getFileManifestEntries until I realised that if I clicked on it then I get the documentation... Would love it if you don't have to make people like me think about what to do.

https://www.womentechmakers.com/ is using Workbox. It's not open source, though.

JSDocs is super restrictive and I think having an intro to each module would be a great way to cover more in depth's topics for each module without creating a crazy IA.

@kaycebasques @jeffposnick @addyosmani thoughts?

There are a few interfaces that changed (like Router; see https://github.com/GoogleChrome/workbox/releases/tag/v2.0.0), and the corresponding examples need to be updated.

I was looking how to configure caching of a CDN resource with the webpack plugin

First looked at webpack get started but no clues how do it

Than looked at CDN How To but the info seems to be for an outdated library version

After digging a bit i found the plugin reference which hints that the options is the same passed to workbox-build

Finally in workbox-build reference i found the runtimeCaching option, so i could simple do:

new WorkboxPlugin({
      globDirectory: DIST_DIR,
      globPatterns: ['**/*.{html,js,css}'],
      swDest: path.join(DIST_DIR, 'sw.js'),
      runtimeCaching: [{
        urlPattern: /^https:\/\/fonts.googleapis.com/,
        handler: 'cacheFirst'
      }]
    })

I hope this report helps improving the docs for new users.