Use webpack/sass-loader to precompile scss files

[ChristophWurst]

Is your feature request related to a problem? Please describe.
We still compile scss files dynamically on the server, although they could be precompiled into our checked-in build artifacts (#13156).

Describe the solution you'd like
Use webpack with scss-loader (in combination with style-loader) to precompile on npm build once #13156 got merged into master.

Not only will it remove load from the server, it will make it possible to bundle more of these style sheets into a single bundle (either together with the scripts or a dedicated style bundle).

Describe alternatives you've considered
Don't change this.

cc @nextcloud/javascript @nextcloud/theming

[rullzer]

Less request => happy @rullzer

[skjnldsv]

What would be the advantages?

[rullzer]

@skjnldsv

• less requests going to storage when needing to serve the file.
• Less on the fly compilation needed on each and every nextcloud after each update

[skjnldsv]

• less requests going to storage when needing to serve the file.

Once compiled, does it change anything?

• Less on the fly compilation needed on each and every nextcloud after each update

This one I totally get. Though you could ask how much weight does this really cost. :)

As a side note, since I've discussed it multiple times, we cannot drop the scssphp module since all of the apps still require on-the-fly compilation :)

[rullzer]

• less requests going to storage when needing to serve the file.

Once compiled, does it change anything?

Well if you have remote storage. (Like objectstorage). When a new user comes in you have to go there. Request the files and forward them.

Also it is extra requests. 1 big blob is faster than 40 little blobs.

• Less on the fly compilation needed on each and every nextcloud after each update

This one I totally get. Though you could ask how much weight does this really cost. :)

Even for me the first load after installing or an upgrade takes significantly longer.

As a side note, since I've discussed it multiple times, we cannot drop the scssphp module since all of the apps still require on-the-fly compilation :)

Yeah that is fine. We can keep it. Apps can still use it. Though I would recommend a lot of apps to just move to the same 1 package file to server. But this is mainly about making the core what we ship faster. We can't control what any 3rdparty app out there is doing.

[skjnldsv]

Though I would recommend a lot of apps to just move to the same 1 package file to server

To move to pre-compilled scss?

[rullzer]

If possible yes

[skjnldsv]

@rullzer that would mean any change made to server won't reflect anymore on the apps. And this goes completely away from the standardisation work I've been doing. If a fix land on 15.0.1 that change a design variable, all the apps will require a scss recompilation.

[rullzer]

Well that of course should be avoided. But a lot of apps don't even use those variables. They can just bundle their css. Baby steps.

The plan is not to break anything. But a lot of things we can improve. A lot of scss doesn't even use the variables I bet

[juliusknorr]

@rullzer that would mean any change made to server won't reflect anymore on the apps. And this goes completely away from the standardisation work I've been doing. If a fix land on 15.0.1 that change a design variable, all the apps will require a scss recompilation.

Are there variables we cannot just distribute via css custom properties? Because then we still can have the flexibility of predefined values from code, but can have precompiled scss.

One thing we need to check is the icon logic included for the accessiblity app. Right now, we pase all the scss files during compilation and extract icons that need to be inverted. We still would need to parse all the css files at some point to keep the accessibility app working the way it is right now, otherwise we probably need to think about a different mechanism.

[MorrisJobke]

Many of them are already done, right? How much is left and should we move them then to 17?