@ducanh2912/next-pwa@10.2.9

Patch Changes

• f3766a5 Thanks @DuCanhGH! - chore(deps): updated all dependencies

  • Monthly dependencies maintenance

  • Not so monthly this time...

@ducanh2912/next-pwa@10.2.8

Patch Changes

• d43ba6c Thanks @DuCanhGH! - chore(deps): monthly dependencies maintenance

@ducanh2912/next-pwa@10.2.7

Patch Changes

• a1f09b3 Thanks @DuCanhGH! - chore(next-pwa): removed clean-webpack-plugin

  • This plugin is... unmaintained, and we could use fs.rmSync anyway.

@ducanh2912/next-pwa@10.2.5

Patch Changes

• e6ce949 Thanks @DuCanhGH! - fix(core): fixed using fallbacks with files in the public directory

  • Silly mistakes... Sorry for the inconvenience.

@ducanh2912/next-pwa@10.2.4

Patch Changes

• 07c8861 Thanks @DuCanhGH! - fix(core): fixed invalid precache manifest with assetPrefix

  • Turns out it is much more complex than we thought. To make this work with assetPrefix, distDir, and basePath, we now remove ${publicPath}${publicDirRelativeToOutputPath} from public files in manifestTransforms because assetPrefix is not intended for files that are in the public directory and we also want to remove /_next/${publicDirRelativeToOutputPath} from the URL, since that is not how we resolve files in the public directory.

@ducanh2912/next-pwa@10.2.3

Patch Changes

• e5f1d14 Thanks @DuCanhGH! - fix(core): fixed invalid precache manifest and scope with basePath

  • A fast backport of serwist/serwist#56.
  • This was caused by "/_next/../public" in modifyURLPrefix not being matched when basePath was set, since the URL was actually "${basePath}/_next/../public/**/*". We now use manifestTransforms instead of modifyURLPrefix.
  • Also, with the refactor to using a context, we mistakenly changed scope from "${scope}" (suffixed with / if originally not) to "${basePath}/${scope}". This reverts that change. Sorry for the inconvenience!

@ducanh2912/next-pwa@10.2.2

Patch Changes

• e583be6 Thanks @DuCanhGH! - fix(disable): fixed disable not working properly

  • In 10.2.0 and 10.2.1, when disable was set, certain unexpected parts were still processed, causing the resulting app to contain some erroneous JavaScript.
  • This has been fixed in 10.2.2. Although we still run parseOptions, we only do so to get the default options.

@ducanh2912/next-pwa@10.2.1

Patch Changes

• aeb0dc9 Thanks @DuCanhGH! - fix(mjs): fixed the ESM build crashing

  • This was due to us referencing __dirname, which was undefined in the ESM build...

@ducanh2912/next-pwa@10.2.0

Minor Changes

• f65e6ab Thanks @DuCanhGH! - refactor(core): create a context

  • We now leverage a context to share the user's options for Webpack, Next.js, next-pwa, TypeScript, etc. across the codebase. This is better than the old approach, which was similar to props drilling, in that it is more readable and less error-prone.
    • I'd like to extend my thanks to the vite-pwa team for this approach! Learned a lot through forking vite-plugin-pwa, that's for sure.
  • Additionally, the codebase now leverages Biome.js instead of Prettier and ESLint. For now, pre-commit hooks using Husky are not available.
  • Edit: Also, an age-old bug in @ducanh2912/next-pwa has been fixed. If you don't provide additionalManifestEntries, @ducanh2912/next-pwa now runs fast-glob on your public folder for you. The old next-pwa, too, did this, but an extra ?? [] in our fork ruined that...

@ducanh2912/next-pwa@10.1.0

Minor Changes

• #130 9ff6c29 Thanks @DuCanhGH! - feat(next-pwa): re-adjust workboxOptions.exclude defaults

  • This was long overdue, so here we are.
  • Why?
    • This proves to be more sensible than the old defaults.
  • Would this incur a breaking change?
    • Technically yes according to my definitions of a breaking change. It will cause a behavioural change in the built app, unexpectedly so for those who don't pinpoint their dependencies' versions. However, I don't believe this has an impact big enough. This... simply improves the user experience, and it won't cause any build to suddenly fail.