Restore ability to compress all files during dotnet publish for Blazor wasm applications

[SwissJimmy]

This issue was previously raised as a bug but was closed as an intentional change.

#3783

Now, only files in _framework folder and appsettings files are compressed.

Regardless, the switch from .net 5 to .net 6 has a subtle breaking change for deployed applications.

Steps to recreate:

1. Using .net 5, deploy a .js file within the "_content" folder.

2. The .br and .gz files will be served when requesting .js file

3. Change the .js file

4. Using .net 6 deploy the same project to the same location

5. The .js file will be changed to the latest version but .br and .gz will remain as older version

6. The .br and .gz files will continue to be served. The changes to .js will be ignored

In addition, the inability to compress all files as part of "dotnet publish" introduces the need for extra scripting to compress files as part of the deploy process. This is particularly important for web applications that depend on large .js or .css files and where there is great pressure to minimize the initial load times of Blazor apps.

Given that there is a project file option to disable compression, perhaps it would be appropriate to add a new option such as:
<CompressAllPublishedFiles>true</CompressAllPublishedFiles>

It certainly is possible to hack the .targets file to compress all files but a more stable solution is required.

[javiercn]

@SwissJimmy thanks for contacting us.

Incremental deployments are not a feature we have. We always recommend doing a clean publish every time. Even when we compressed all the files in the past, the compressed versions were only served for Blazor files, hence why it was deemed a bug and not a feature.

We do plan to bring back compression at some point in the future for all static web assets (not just Blazor) but as a proper feature and not a bug.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[javiercn]

Compression was moved to the static web assets SDK and can be configured independently by the app. cf2977b57b576dcff270d0baf8ef7aa007d63e2d