Workbox用于Progressive Web Apps的JavaScript库集合

🎉 What's New?

The latest alpha release of Workbox v5 includes the following developer-visible changes, in addition to all the changes from the previous pre-release.

TypeScript support

All browser-based Workbox packages are now written in TypeScript and type definitions have been published to npm. TypeScript users (as well as users with TypeScript-aware code editors) can now get type checking for all browser-exposed Workbox APIs. (There are no TypeScript definitions for the various Workbox build tools at this time.)

To get type definitions for any Workbox APIs, you can import the package as described in our guide on Using Bundlers (webpack/Rollup) with Workbox. For example:

import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';
import {Plugin as ExpirationPlugin} from 'workbox-expiration';

registerRoute(
  /\.(?:png|gif|jpg|jpeg|svg)$/,
  new CacheFirst({
    cacheName: 'images',
    plugins: [
      new ExpirationPlugin({
        maxEntries: 60,
        maxAgeSeconds: 30 * 24 * 60 * 60, // 30 Days
      }),
    ],
  }),
);

Note, we've historically published our Workbox source modules with the .mjs extension as a way to disambiguate them from classic scripts and the examples in our documentation that reference file paths always use .mjs.

However, since TypeScript does not currently support importing .mjs files we publish both .js and .mjs files to npm. TypeScript users wanting to import an individual module should be able to reference it by omitting the extension (which will then default to the .js file).

import {registerRoute} from 'workbox-routing/registerRoute';
import {CacheFirst} from 'workbox-strategies/CacheFirst';
import {Plugin as ExpirationPlugin} from 'workbox-expiration/Plugin';

If you encounter any problems with the type definitions or importing the source files via TypeScript, please let us know by opening an issue on GitHub.

Note: The only browser-based Workbox package we haven't converted to TypeScript is workbox-sw, which we don't recommend using with bundlers. As mentioned in the v5.0.0-alpha.0 release notes, our build tools are shifting away from a dependence on a CDN. However, if there are strong use-cases for wanting type definitions for workbox-sw, please let us know, and we can re-evaluate.

🐛 What's Fixed?

Build Tools

• Fixed an incorrect assumption about the location of node_modules, which could lead to a failed generateSW build process. [#2110]
• Opt-out of auto-discovering a local Babel configuration file, and instead always use the default @babel/preset-env configuration during the generateSW build process. [@2113]

workbox-window

• Added the isUpdate property to the controlling event, which was documented but not actually implemented. [#2114 ]

Thanks

Special thanks to @kaykayehnn for their bug reports and contributions that went into this release.