Add default pwa manifest and service worker file

[dhh]

Having the PWA manifest and service-worker.js files under app/views/pwa means we can work on them dynamically with ERB and other techniques. They're mounted via a built-in Rails controller and explicitly revealed in the routes.rb file to ensure there are no surprises.

• Consider adding --skip-pwa, although I'm not sure that's needed. This feels like default files akin to 404.html and icon.png.
• Add some tests?
• Explain the example code in service-worker.js better? Or wait for Action Notifier to drop to integrate it out the box?

[joemasilotti]

What’s the general consensus on acronyms like PWA? I usually add them to the inflections file so we can PWAController and such.

[dhh]

I don't find it worth adding custom inflections. Pwa is imo fine.

[rossta]

It could be helpful also to generate the serviceworker registration script and add an import statement into application.js to get the serviceworker running in the browser. In serviceworker-rails, it's called the serviceworker companion:

if (navigator.serviceWorker) {
  navigator.serviceWorker
    .register("/service-worker.js", { scope: "./" })
      .then(function() {
        console.log("[Companion]", "Rails Service worker registered!")
      })
      .catch(function(error) {
	      // registration failed :(
        console.log("[Companion]", "Rails Service worker registration failed: " + error)
      })
}

https://github.com/rossta/serviceworker-rails/blob/a81aa1f138716e4eda8c1241c8b8152c1b1bda9c/lib/generators/serviceworker/templates/serviceworker-companion.js#L1-L11

[dhh]

@rossta Yeah, going to tackle that in Action Notifier, since that's the default usage of service workers we'll ship with in Rails 8.

[rctneil]

I think stuff like this is nice, but by default it only applies to new apps. How do we know what to add to get the same in an existing app?

Same question applies to other features in 7.2 and other rails updates. Please don;t just focus on new apps. Tell us what to do to add these new and cool features to our existing apps. What changes we need to make.

I keep seeing people say that they want to make Rails easier for people to learn but stuff like this just keeps getting skipped as far as I can tell.

I could be wrong, If I am then point me in the right direction and i'll go read!

Thanks!

[dhh]

@rctneil Would be nice to include a link in the release notes, but it would probably just be to this exact PR. As you can see, it's not very big. You can literally just copy and paste these files into your applications and have what a new application would have.

But please do volunteer to help document some of this stuff better, and you find your way through it. Always great with another pair of eyes on it who haven't been part of the development itself. Thanks for helping!

[rctneil]

@dhh I'll see what I can do. I just feel that if something new is added to Rails, then it should be explained how to get it / use it for both new apps AND existing apps.

Could the release notes for tommorrow be updated to include details of how to do this for this, devcontainers and Rubocop and Omakase. It'd also nice to add notes on what each of these things are as not everyone knows what they are or what they are used for. This last one I have no clue. Need to look rubocop and omakase up. some notes would be useful. I hope you agree?

[dhh]

Yeah, good to link up projects to where you can learn more about them. Please do pitch some patches!

[rctneil]

@dhh I'll try, but need to look into them myself first. I don't any anything about the items i mentioned. I just read about them in the RC1 release notes and literally said to myself "Huh? Sounds cool but I don't know what they are".

New features are cool, but documentation needs to tell us how to use them.

I'll leave it at be now. I've explained enough. No need for me to keep pushing my point as I have a habit of doing, :-)

[davegson]

@rctneil check out the amazing raildiff project.

You can pick two rails versions and see what differences between new project in each are, eg: diff between 7.1 and 7.2.2:
https://railsdiff.org/7.1.0/7.2.2

for this case, it shows all new PWA files for easy copy paste. I've been heavily using it since I found it.

Might even be worth linking to in the upgrade guides @dhh?

[trebeil]

@davegson @dhh @rctneil Regarding the discussion about how to add the new features to existing apps when upgrading from previous versions:

• I'm in the process of upgrading an app from 7.1.5.1 to 7.2.0
• I was also confused that The Update Task mentioned in the Rails Upgrading Guide did not: 1. generate all new files necessary to make use of some new features, e.g., the new PWA files, the new GitHub CI workflow files; 2. update existing files to make use of added features, e.g., the Gemfile was not updated to add brakeman and rubocop-rails-omakase but the brakeman and rubocop binaries were created anyway, generating an error when I tried to execute these binaries.
• I believe/understand that starting off with Rails defaults is normally the best way to go further, since its the philosophy behind Rails anyway (omakase, right?) and so, when upgrading to a new version of Rails, I would like to have all new features and defaults applied to my existing application and then be able to analyze the diffs and eventually accept or revert changes
• Doing that by looking at each pull request and copying/pasting files and changes by hand, as suggested by @dhh, is impractical. The RailsDiff tool mentioned by @davegson is a better way, but I think it's still not ideal, since: 1. it still requires copying/pasting lots of files; 2. the diffs shown in the tool consider files created with the default rails new <app_name> command and many times applications are generated with additional specific options, e.g., rails new <app_name> --database=postgresql. In these cases, the diffs shown may not contain all necessary code.

I ended up trying something that I believe may be a better way of doing this:

1. I ran The Update Task mentioned in the Rails Upgrading Guide, specifically to get the file with detailed new framework configuration defaults and analyze/test/accept them one by one
2. After ensuring that my application works with the new configuration defaults, I went to the parent folder of my application and I ran rails _7.2.0_ new <app_name> [options]. This command in fact tries to generate the whole application from scratch and so generates all files for the new features. It obviously finds a lot of conflicts with existing files and asks for permission to overwrite, all of which I accepted.
3. After that, it was just a matter of resolving diff conflicts directly in my code editor, which I think is much safer (and easier) than trying to ensure that you have copied/pasted all framework changes manually

I'm relatively a newbie (started coding 2 years ago) so I don't know if all this was the obvious way of doing it, but to me it was not obvious at all. But now, it looks to me like the best way of doing it.

So my questions are:

• Isn't this the best way of ensuring that you get all new features and configurations when upgrading a Rails app?
• If so, would it make sense to document this idea in the Rails Upgrading Guide?

If so, I would be happy to write a PR to update the Guide. Just wanted to be sure first that this makes sense.

[dhh]

Automatically opting you in to all new default features has never been a design goal of the upgrading tool. It's been to ensure compatibility, and then you can start using features as you see fit. I'm much more concerned about someone using the upgrade tool, turning on user-facing features, and getting surprised in production than I am about users of existing apps having to manually opt-in to new features. So I don't see that stance changing.

That being said, there possibly could be a way to have our cake and eat it to. We could have an interactive upgrade step where we prompt the user for the opt-in permission to add new features to the app, like PWA default files, etc. I don't personally have an interest in working on that, but if someone is inclined to explore, I wouldn't oppose it.

[trebeil]

Yes, makes sense. Its just that to me, it seems that having the upgrade tool add all new features and opt-out by deleting files or rejecting code changes is much easier than having it adding only some stuff and than having to manually opt-in by searching for what you may have missed and copying/pasting. Besides that, if a new Rails app comes by default with these new features, it's because it was discussed a lot, it fits the vision of the maintainers and it's considered the best default from now on (again, omakase), right? So when I was upgrading to this new version, I was intuitively expecting everything to be added automatically and then being able to opt-out instead of have the minimum added and having to manually opt-in.

I think an interactive upgrade step prompting for the opt-in permission to add new features would be the best solution indeed. Right now, I wouldn't be able to work on this too, so I thought that at least mentioning on the Guide the idea of using the rails new generator as a way to ensure that you get all the files and changes for the new features and then opting-out by deleting files and rejecting code changes could be helpful. Again, as I'm new to all of this, I don't know if this approach was obvious or if its not even desirable at all. If so, no problem. In my personal notes, I've documented this approach to be my standard when upgrading anyway.

[dhh]

I don't see a path where the automated upgrade just adds a bunch of new features that have user-facing consequences without explanation or confirmation. I wouldn't want that. If your application is already in production, it shouldn't just change underneath you.

Anyway, appreciate your input, and the invitation is open to anyone who wants to explore the interactive option.