Compress css with nodejs

[Morlinest]

Minify css only when building gitea so we can develop, debug and compare changes. JS should be add in the future.

Also needed for changes in building gitea with drone - including docker image with node instead of installing node on drone build.

[codecov-io]

Codecov Report

Merging #2580 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2580   +/-   ##
=======================================
  Coverage   27.33%   27.33%           
=======================================
  Files          86       86           
  Lines       17137    17137           
=======================================
  Hits         4684     4684           
  Misses      11775    11775           
  Partials      678      678

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fa6d7c7...48cd7da. Read the comment docs.

[lunny]

why recovery this css file?

[lunny]

Put the unminify content on git should be friendly to develpers, so I agree with this change.

[lafriks]

index.css file should be left minimized

[daviian]

Maybe rename this build step to minify-stylesheets ?

[lafriks]

@daviian this step will later be used also to minify js files etc, so can be left as is

[Morlinest]

@lafriks That's exact reason for that name.

[lafriks]

I'm somehow against it. Development should be done in .less files and if you want to experiment you can unminify in browser

[Morlinest]

@lafriks @lunny There are few reason why I think css should be unminified til build process:

1. To be able to use pre-build step with nodejs (we are using only "go" or only "nodejs" image, "generate css + minify" needs both images)
2. To be able to develop and test on local env without need to change less and regenerate css all the time
3. To be able to check existing styles and rules in development/test
4. To be able to check changes done in less file and the corresponding changes in css
5. Same workflow will be applied for JS, it is better to be able develop and check changes before minifying it

Another question: If we add JS to "minify", would you like to have 2 different workflows for JS and CSS?

[lafriks]

@Morlinest

1. I'm not against this
2. You will still need to make changes in less files so I don't see point on making changes first in css as this is duplicate work and you anyway in the end need to regenerate css and there is chance that you can lose some of work
3. What do you mean here? (You can check rules in browser dev tools also from minimized)
4. We need to check only less changes in PR, drone ci step will verify that css file is correctly updated
5. For js there will still source files and that is only thing we need to verify, drone will check minified

[lafriks]

As for your question it should be same workflow.

[Morlinest]

@lafriks OK, I agree with you about no need of not minified version of css.

Now look at #2581. Stylesheets test is based on differing before and after generating it from less file. But minify is part of go env, not js env. The only solution I see for this is to use "nodejs minify" instead.

For JS, you want to create *.min.js from *.js and use it inside template? What about development, debug?

[lunny]

LGTM

[lafriks]

Minify can be changed to nodejs version, I see no problem with that.

As for js files there should be single js file built from multiple js files. Both minified and unminified can be built and as we already have mode in app.ini (production/development) that can be used to include either minified or unminified version

[Morlinest]

I forgot about modes app.ini. I'll try do some changes.

[Morlinest]

@lafriks Changed PR to just minify css with nodejs instead in single step.

[lafriks]

LGTM