RFC: PWA Plugin #717
Comments
|
Hey @yyx990803, I wanted to test this out so I cloned the repo and tried to follow the steps in "Development Setup" from the readme but However, after I manually selected the features, it failed to scaffold the project: What do I need to do to make this work? Another question I had was, what about the documentation? Would each plugin have it's own documentation? Right now, the documentation for the PWA template is mostly similar to the webpack template but there is some additional documentation which touches upon things like service worker. Is there anything else that you'd like me to help with? Edit: Tests are failing as well.
|
|
I'm excited about this direction of encapsulating PWA functionality into a vue-cli plugin. I've handed maintainace of the PWA template to Jeff but am supportive of deprecating it in favor of the plugin once we can confirm feature parity. Love the idea of no longer needing to keep in sync with the upstream changes to the webpack plugin. Thanks for looping us in, Evan. We'll take a look. |
|
Similar to the comment above, instructions on running the plugin for scaffolding would be greatly appreciated. Currently seems to error out. |
|
@sudo-suhas it seems to be Windows related.
@addyosmani if you are on macOS it should work as intended, let me know if you are running into problems as well. |
|
Re docs: we can have each plugin document itself in its |
|
Yes, it is related to Windows(it usually is 😉).
I actually do not see any errors: I got an error when I tried this the first time because I had the stable version of
Still faced the previous issue.
Tried this, but it fails due to symlinks. Regarding symlinks, I have a couple of questions
|
|
@sudo-suhas so turns out you need to specify type to be |
|
That sounds like a solid plan, @yyx990803. And thanks for continuing to work on this, @sudo-suhas—I'm happy to follow your lead if you're able to get the initial port working. Do you have your experimental code pushed anywhere public right now? One of the improvements that I'm interested in making with the PWA template is switching over from |
|
@jeffposnick switching the plugin should be dead simple, just swap out this part as long as it generates the same As for preload plugin - I have it included in the base setup by default now with a forked version here. When my change for |
|
@yyx990803 I managed to advance a few steps after the recent bug fixes you made. However, the scaffolding now fails in the lint step. Here's the debug logs - vue-create-app.debug.txt I tried running the
It's pretty awesome that I get to collaborate with the people I admire and look up to. So it's a win-win 😄.
Right now, the packages the test-app depends on aren't published and they are instead supposed to work via symlinks to binaries in the monorepo. I have published the app which I just created here - sudo-suhas/vue-pwa-next. But this will mostly be just a read-only repo. |
|
@sudo-suhas that error log is again quite weird... it seems you don't have |
My apologies, was able to create the app without errors after this. But the symlink isn't working correctly: I'll try to look into this since it will be hard to debug without a Windows machine. |
|
So here's my findings for symlinks:
Unfortunately, even The only way that I can think of solving this is using |
|
@sudo-suhas ha, I didn't realize it's such a hassle to symlink an executable in windows... yeah I guess we can just do what yarn is doing here |
|
Okay, I'll do these changes and make a PR to the |
|
@sudo-suhas I got that in db9be90 so I can have others using windows test it, but thanks for investigating this! |
|
As a side note, would be willing to accept a PR which switches over to |
|
@sudo-suhas I intentionally didn't use it because we only want the config file in one deterministic location, plus, |
|
I just spent some time looking through the new plugin architecture in more detail—it's really nice, and I was happy to see that so much of I have a branch that uses the current alpha release of Workbox instead of One thing that I'm not sure about if whether there's anything I could do to expose the options passed to the Workbox webpack plugin to the developer. I could imagine, for instance, that a developer might want to pass in an additional @yyx990803, are you interested in a PR for that change, given that it's still an alpha release of Workbox? In other words, are you okay with merging in code to the |
|
@jeffposnick good to know! The second module.exports = {
pwa: {
workBoxPluginOptions: { ... }
}
}Then in the plugin you can read: module.exports = (api, options) => {
const userOptions = options.pwa || {}
const workBoxOptions = Object.assign(defaults, userOptions.workBoxOptions)
}As for workbox, how far along in the future do you think it will stabilize? We still have some work left before we officially release vue-cli 3.0, so it would be ideal to coordinate. If we don't have something stable by the time we are ready to release then I think it's better to stick with |
|
Thanks, @yyx990803. The We're shooting for a Workbox v3 final release by the end of January. We're at the stage where we're just testing out various integrations (like this one) and fixing any bugs/pain points that remain. How does that track with the |
|
@jeffposnick that should work out nicely! We'll most likely still be in alpha/beta state around that time. We can take a PR to switch to workbox |
|
Update: we have started making alpha releases! You can now directly test the new CLI by following the guide in README. |
|
@jeffposnick any updates regarding workbox v3? Open to a PR to migrate to |
|
We just hit beta yesterday (rather than final, as was our original goal): https://github.com/GoogleChrome/workbox/releases/tag/v3.0.0-beta.0 I'm happy to file a PR to migrate to the beta release to coincide with the alpha releases of the CLI. Stay tuned. |
|
For what is worth, I've just migrated a personal POC app that used the PWA template along with vuex and the migration when smoothly. I'll test it in the next days to see if anything comes up, but for now the experience has been painless |
|
I moved an existing project over to using this template with the cli beta and I found that the service worker didn't behave as I expected with the existing configuration. Problem: The current configuration only returns This leads to "No Internet Connection" errors in the browser because nothing in the cache matches the route requested. I expected navigation calls to always return Proposal: Change the workbox default settings in workboxPluginMode: 'InjectManifest',
workboxOptions: {
// swSrc is required in InjectManifest mode.
swSrc: 'src/service-worker.js'
}And the default contents of /* globals workbox */
// Workbox is automatically imported when this is built for production.
workbox.precaching.precacheAndRoute(self.__precacheManifest)
workbox.routing.registerNavigationRoute('/index.html')
// Service worker custom application code goes below this line.I think this has two main benefits:
If this sounds good, I'm happy to put together a PR with these changes. |
|
To give some perspective,
My gut was to ship with navigation fallbacks disabled by default, and then we can explain to developers that want that behavior to make the following changes to their configuration in order to enable it. (You don't actually have to go the workboxOptions: {
navigateFallback: 'index.html',
}If there's consensus, I'm not against making that configuration (along with workboxOptions: {
navigateFallback: undefined,
} |
|
Thanks for the background on this issue from But, if not... It's my view that supporting pushState navigation out of the box is a very desirable feature, especially in a PWA template that will almost always have a single app shell html file. Some background on how I came into this: I generated a project from this template and I was looking for somewhere to hook in some push notification subscription/handlers. As I had never done this before, let alone integrated it with this template or the Vue build process, it wasn't clear to me where it should go. I see two ways this could be improved: Config Options With these options: {
workboxPluginMode: 'GenerateSW',
workboxOptions: {
navigateFallback: 'index.html',
importScripts: ['/custom-service-worker.js']
}
}Benefits:
Downsides:
InjectManifest With these options: {
workboxPluginMode: 'InjectManifest',
workboxOptions: {
swSrc: 'src/service-worker.js'
}
}And the generated/default content of Benefits:
Downsides:
I'm for either of these solutions, with a slight preference for the second one. In any case, this template is really great and I went from an existing traditional SPA to a PWA with 90+ Lighthouse score in a couple of hours. 👍 |
/cc @addyosmani @jeffposnick @sudo-suhas
So, I've been working pretty hard on the next version of
vue-cli, which uses a completely plugin-based architecture, and the PWA functionalities are now fully isolated in its own module: https://github.com/vuejs/vue-cli/tree/next/packages/%40vue/cli-plugin-pwaA brief intro for the plugin API:
index.jsis the runtime plugin that will be loaded when users runnpm run serveornpm run build.generatorcontains a module that will be invoked when the user scaffolds the project with the globalvuecommand. The API should be pretty explanatory, and seems to cover most use cases. But any feedback is greatly appreciated.Our previous PWA template is a fork of the main webpack template and has trouble keeping up with the upstream changes. This new setup should greatly reduce the maintenance scope for PWA-related features in the future.
After the launch of
vue-cli3.0, we should deprecate the pwa template and move all collaborations under the plugin instead.The text was updated successfully, but these errors were encountered: