PWA module 3.x roadmap

I'm interested! Just let me know.

I have some time to help.

Let's arrange a date and time. I am flexible every day this week between 9:30am PDT and 6:30pm PDT, except for today, Tuesday, when my availability ends at 5pm PDT. But I am perhaps the least important person here. @nod_ and @AlexBorsody are the key people. So don't let my availability stop you from meeting.

If memory serves, Alex has looked into workbox for quite a bit, but eventually modeled the 8.x service worker after the 7.x one due to assumptions in workbox that didn't hold true in Drupal.

I would love to see support for multiple configs through domain access. Is it possible? I filed a request here: https://www.drupal.org/project/pwa/issues/3210576

Hello there. I'm also interested in helping out with this. I specialize in system architecture stuff, so refactoring this module, especially the PHP side, is something I'd be interested in. Also definitely interested in getting Workbox up and running for this too, as I have JavaScript experience as well.

Let's clarify the branch workflow we are having.

Essentially 2.x is a fork of the 8.x-1.x codebase. It is a port of 7.x-2.x to D8 with the most significant changes being the move to a Workbox based service worker.

The original service worker created by rupl using vanilla js is on both 8.x-1.x and 7.x-1.x, it is reliable and tested, I have it on two sites myself and it works for my purposes of Cache API offline handling and performance. 8.x-1.x is also the recommended branch an end-user downloads right now.

What doesn't make sense is doing some PHP/Drupal improvements to the 2.x branch and some to 8.x-1.x with no consistency, this is happening now.

Right now the only work that has been done on 2.x from this thread is #3241098: Update default logos to use the evergreen Drupal logo.

This and all other PHP improvements not related to the Workbox service worker should be assigned to the 8.x-1.x branch as well or applied only there until the Workbox port begins.

All PHP code improvements suggested here should be applied to the recommended and supported branch 8.x-1.x for now and can later be ported to 2.x when the Workbox development actually starts there (I will be able to help in the coming months on this).

When the port of 2.x to Workbox begins, we can still keep the 8.x-1.x branch minimally maintained for those who have found the existing service worker to be stable and don't want to risk a major update that could cause unexpected issues.

Let me know your thoughts in trying to keep this development organized.

@AlexBorsody I don't disagree. I think my assumption was that the 2.x work listed above could potentially introduce some API changes especially if there's a lot of PHP code clean up or refactoring, but I think in hindsight you're right and the 1.x branch can benefit from most of this without any breaking changes.

@AlexBorsody I was thinking of starting work on #2914372: Split admin config UI into multiple tabs; should I set that issue to the 8.x-1.x branch from 2.x?

Yeah please, I think everything D8/9 should be on 8.x-1.x right now. No need to create a fork.

Things were getting confused in the issue queue with these two branches, and no real compelling reason to maintain two codebases.

Like you said.

the 1.x branch can benefit from most of this without any breaking changes.

Done and created the issue fork but will get to the actual PHP code another day.

Added link to #3241098: Update default logos to use the evergreen Drupal logo in issue summary.

Hmm. Opened a merge request to rebase 2.x to the latest 8.x-1.x since I don't have push access to 2.x but then realized that would just make things unnecessarily complicated and also my brain is tired tonight so @AlexBorsody can you take a look? I don't think 2.x has any 2.x-specific stuff in it yet so you should just be able to reset it to the latest 8.x-1.x commit.

Taking this over with nod_'s permission; added "Code quality improvements" sub list.

Replaced the whole "Serviceworker" sub list with a link to #3060760: Use Google Workbox library as it's now all detailed there.

Moved original summary text to a quote at the end.

Created and added #3268065: Merge pwa_extras into main module to summary.

Added link to #3202990: Make the PWA installation block button customizable

Added link to #3268067: Add Clear-Site-Data and related route for 2.x.

Sorry for dropping off the radar; work and paying the bills has been the priority the last few months. I do intend to get back to this when I can, but if anyone wants to get on some of the tasks, feel free, and I'll review when I'm able to.

@maintainers: Looking at D10 compatibility and 8.x-1.x vs. 2.x could you perhaps give a short update about D10 compatibility plans?
Here and at #3289196: Automated Drupal 10 compatibility fixes perhaps? Currently the module is blocking upgrades, so it *might* make sense to make both versions Drupal 10 compatible for now?

Thanks :)

PS: Thank you for your great work here!!

@Anybody I agree adding Drupal 10 compatibility to both branches makes sense. I can take a look when I have some free time, but that's been in short supply lately.

Having a look at all the issue, I think it might make much sense to first fix all clear bugs in 8.x-1.x and especially write tests!
After that I guess it would make sense to start over with 2.x based on 8.x-1.x otherwise we'll have a high risk to run into regressions or have to do a lot of work twice.

So I'd suggest to reset 2.x to 8.x-1.x or even remove it and start over here later... what do you think?
Also for example see issues like #3070130: Create pwa_webpush submodule to manage push notifications where code was committed to 2.x but now seems to be missing. 2.x status seems to be a (dangerous) mystery :D

@Anybody There are a few commits to 2.x that were added either because they didn't make sense in the previous branch or broke compatibility, so we'd lose those if it just gets reset. I'd rather keep the branch and merge from or rebase onto 8.x-1.x every so often to keep it up to date.

I look at 2.x as the long term goal we're working towards, while 8.x-1.x is the current default out of necessity to have a stable release without breaking much if possible.

As for #3070130: Create pwa_webpush submodule to manage push notifications, I took a look in GitLab and I think the reason for the confusion is that that likely got merged into 2.x but then also into 8.x-1.x, or at least that's what GitLab seems to think. I believe we had 2.x set as the default branch but then switched back to 8.x-1.x for the time being, and the issue didn't update to reflect that. I'm not sure where the module ended up and suspect it got removed in another issue somewhere. Might be good to check the commit log for the directory.

@Ambient.Impact thanks! Could you perhaps also have a look at #3289196: Automated Drupal 10 compatibility fixes and especially my comment in #25?

I'd suggest we should clean up the status of 2.x or create a semVer 3.x to work on, while the changes in 2.x can still be made?

@Anybody The differences between 8.x-1.x and the 2.x branch are pretty minor, so it should be possible to just switch over and remove Drupal 8 support from 2.x while marking 8.x-1.x unsupported at the same time. That's what I would do. Then we move everything that was planned for 2.x to a new 3.x branch; this issue will need to be renamed, and the project page updated.

@Ambient.Impact thank you for the plan! Let's do that. So in a first step someone has to compare 8.x-1.x and 2.x as I think some fixes only went in 8.x-1.x, while some features only went in 2.x.

Are you planning to do this? Should we? Perhaps better use a fresh issue for that?

@Anybody Lucky for us, GitLab can tell us exactly what's in 2.x that's not in 8.x-1.x. ;)

My recommendation would be to start a new issue for the new direction for 2.x, and rename this current issue (and the project page) to refer to 3.x. I'm fairly busy with other stuff, so I'll leave the rest up to you.

Thanks @Ambient.Impact! I first cherry-picked the 8.x-1.x issues where cherry-picking was still possible into 2.x separately to have a more transparent changelog.

Now I've created #3349129: Merge 8.x-1.x fixes into 2.x and switched #3289196: Automated Drupal 10 compatibility fixes to 2.x.
Would you mind to set 2.x the default branch?

Unfortunately, I don't seem to have access to the Drupal.org GitLab settings for this project so I can't change the default branch. You'll have to ping one of the other maintainers for that. The Drupal.org Slack #progressive-web-app channel might be the way to go, or messaging them directly on Slack.

I feel like I probably have the perms to change the default branch (I see I'm a maintainer in the GitLab UI at least) but I've never done such a change. Can you please point me to either a docs page or screenshot what I need to do?

Of course, posting a comment was my rubber-ducky :)

So, I only see 8.x-1.x in the list for the repo. Does the branch need to be pushed or am I looking in the wrong place?

@rupl thanks! For now just select 2.x please. Perhaps it will be possible to also grant further permissions to @Ambient.Impact and me?
We'll have to create 3.x once 2.0.0 was released, I think... and give it some days to detect possible bugs.

New settings were just applied: 2.x, with "Auto-close referenced issues on default branch" enabled (it was already enabled when I arrived on the config to adjust branch)

I have a Drupal 9.5 website and the PWA 1.6 module installed. Is there an update path to version 2? THANKS

2.0.0-rc1 is equal to 8.x-1.6 plus Drupal 10 compatibility from this issue.
No upgrade path needed. 2.0.0-rc1 should just work. (But please always take a backup before)

ok thanks

@Anybody @Ambient

pwa_push was removed just a few days after being commited: https://git.drupalcode.org/project/pwa/-/commit/6f8359399b41bc78cd83ae42...

Nothing regarding web push notifications has been commited on 2.x since then.

Heck yeah, glad to see a release!

@rupl I usually uncheck "Auto-close referenced issues on default branch" because that would close all GitLab issues that are set to the previous default branch, which could be really confusing. Both GitLab and GitHub have similar options and I always uncheck when I change the default branch them because most projects I have issues for would be throw into disarray by it. Thankfully, it has no effect here because Drupal.org has its own issue system separate from GitLab, but if it hadn't, that would have closed every single 8.x-1.x issue. 😉

@GuillaumeDuveau I never had a chance to work on that but if I recall correctly, the reason it was removed was because it wasn't fully supported on all platforms (probably Apple, ugh) and/or it was going to be merged into the main module. As far as I'm aware, that functionality is definitely planned for this module, since that's a crucial feature for a lot of use-cases of this module.