marcusasplund / hyperapp-RxJS

A test with HyperApp and RxJS
MIT License
14 stars 1 forks source link

An in-range update of workbox-build is breaking the build 🚨 #56

Closed greenkeeper[bot] closed 6 years ago

greenkeeper[bot] commented 6 years ago

Version 3.3.0 of workbox-build was just published.

Branch Build failing 🚨
Dependency [workbox-build](https://github.com/googlechrome/workbox)
Current Version 3.2.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

workbox-build is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details - ❌ **continuous-integration/travis-ci/push** The Travis CI build failed [Details](https://travis-ci.org/marcusasplund/hyperapp-RxJS/builds/393757116?utm_source=github_status&utm_medium=notification)

FAQ and help There is a collection of [frequently asked questions](https://greenkeeper.io/faq.html). If those don’t help, you can always [ask the humans behind Greenkeeper](https://github.com/greenkeeperio/greenkeeper/issues/new).

Your Greenkeeper Bot :palm_tree:

greenkeeper[bot] commented 6 years ago

After pinning to 3.2.0 your tests are still failing. The reported issue might not affect your project. These imprecisions are caused by inconsistent test results.

greenkeeper[bot] commented 6 years ago

Version 3.3.1 just got published.

Your tests are still failing with this version. Compare the changes 🚨

greenkeeper[bot] commented 6 years ago

Version 3.4.1 just got published.

Your tests are still failing with this version. Compare the changes 🚨

greenkeeper[bot] commented 6 years ago

Version 3.5.0 just got published.

Your tests are still failing with this version. Compare the changes 🚨

Release Notes Workbox v3.5.0

πŸŽ‰ What's New?

More customization when generating a service worker

Developers who use Workbox to generate their service worker (using the CLI, Node interface, or webpack plugin) can now take advantage of some additional options:

  • Setting offlineGoogleAnalytics: true will automatically add code to initialize Workbox's offline Google Analytics support in the generated service worker.

  • Both fetchOptions and matchOptions can now be used when configuring a runtimeCaching route, and those values will be passed through when constructing the corresponding Workbox caching strategy. Many thanks to @peterjosling for contributing this in #1608.

  • Using a custom plugin within a runtimeCaching route is now possible, thanks to enhancements made by @tsirlucas in #1598.

Here's a snippet of Workbox's build configuration, showing off all of the new features:

{
  // ... other options ...
  offlineGoogleAnalytics: true,
  runtimeCaching: {[
    urlPattern: /abc/,
    handler: 'staleWhileRevalidate',
    options: {
      fetchOptions: {
        mode: 'no-cors',
      },
      matchOptions: {
        ignoreSearch: true,
      },
      plugins: [{
        cacheDidUpdate: async ({cacheName, request, oldResponse, newResponse}) => {
          // Do something in your custom plugin.
        },
      }],
    },
  ]},
}

Support for the PATCH method in Workbox's router

Developers who need to match HTTP PATCH requests using Workbox's router can now do so, thanks to @kevin-brotcke's change in #1618.

Note that non-GET requests can't be added to a cache, so this is most useful when used alongside a network-only strategy configured with the Workbox background sync plugin, in order to retry failed PATCH requests once the network becomes available.

workbox.core.registerQuotaErrorCallback is now publicly visible

Due to a scoping error, the workbox.core.registerQuotaErrorCallback() function was previously not exposed. This is now public, matching the documented interface. Thanks to @Tronil for pointing out this discrepancy in #1616.

πŸ“– Learn More

Check out our docs @ developers.google.com/web/tools/workbox/