Gitea: Remove public/css from git

[silverwind]

Having public/css tracked in git causes merge conflicts on any CSS change. Can we remove it from git and require a working Node.js installation to build the CSS?

Regarding release builds, can someone shed some light on how they are done? Would we need add Node.js installation to the Dockerfile for the releases to be able to build CSS?

[lafriks]

Problem is that you won't be able to build gitea from source without nodejs

[silverwind]

Yes, it would be a build requirement, just like golang is. I really think that is not too much to ask for, it's available pretty much anywhere.

[silverwind]

Also, it will be a requirement for proper frontend JS packaging, so I see it unavoidable to depend on it.

[techknowlogick]

Related to #6203 (this is CSS, the other is about JS)

[silverwind]

It will also require a working internet connection towards npmjs.com to download the modules required for the CSS build.

Generally I'm in favor of downloading all build dependencies (including go modules) on-demand rather then vendoring them.

I see that the golang community prefers to vendor dependencies, which may come from the fact that golang has no central repository for its modules, but in the JS world it's the accepted way to depend on the npm registry. The only other option is to vendor node_modules which was heavily rejected the last time I tried that.

[sapk]

@silverwind I think the vendoring for go projects will drop with module (select the needed version from local cache and not the one in GOPATH), the creation of go proxy/cache for Go1.13 (that will limit the downtime and disapearing module) and mostly the fact that depending libs are more stable than before (less removal or rename)

[sapk]

For the docker build, we will need them at the build stage to build the binary but not at the last (release) stage.

[silverwind]

I think the vendoring for go projects will drop with module

But even with a local cache of go modules, isn't it still quite risky to depend on GitHub repos? When they are deleted, it would break our build, right?

In contrast, npm guarantees that no package is ever deleted (except in a very limited timeframe after publish).

[sapk]

Go1.13 will support mirror/proxy that will mitigate that problem (if the licence permit it). https://blog.golang.org/modules2019
https://twitter.com/FiloSottile/status/1123325054794657792?s=19

[lunny]

@sapk that will not work on China and as I know also there are some offline workspace which will never not connect to internet.

[sapk]

@lunny It already exist some open-source implementation of the proxy. They hope that some proxy will be maintain by local community and the proxy and sum server is configurable.

[silverwind]

@lunny Is a offline build a requirement?

We should decide either to ship everything (vendoring both golang and node modules) or nothing (pull from npm/go proxy on build) in git.

[techknowlogick]

We can compile and run gitea offline without vendoring node modules, but we can't without vendoring go modules.

[silverwind]

Currently yes, but only because JS modules are vendored in a non-standard fashion. Once those move to node_modules it would need to be vendored to support offline builds. It is standard nowadays to source JS from node_modules, ideally via a bundler like webpack.

[lunny]

except nodejs, could we have any other options to organization javascript modules?

[silverwind]

Not that I'm aware of. Bower was at one time the primary frontend package manager, but its days are past and everyone today seems to rely on either npm or yarn, both which build a node_modules folder and bundlers like webpack or parcel source the modules from there.

[silverwind]

The recent introduction of the JS build process brought up this pain point again for JS. Every time we push a JS change, all pull requests with more JS changes will conflict. This is very bad for testing among other things.

I think it's time to drop them from git and require Node.js as a build-time dependency.