Track style css

[cryptix]

This updates #51, 100kb is an arbitrary upper bound.

I checked in a production build of style.css (13kb)

@staltz can you remind me under which circumstances we need to regenerate that file?

[staltz]

web/assets/style.css is:

• in dev, a 3MB file
• in prod, usually less than 100kB

For that reason I don't think we can put web/assets/style.css in git, because to develop the frontend we'll be needing the full 3MB file, to avoid having to generate web/assets/style.css for every (or most) template changes.

[cryptix]

hmmm... but that means we need to run go generate before building the server for deployment.

Can't we check in the prod style.css and let frontend devs overwrite it (by running go generate -tags dev) with the big one when they want to hack in it?

[staltz]

I feel like this is that same discussion about putting generated code in git. Wouldn't Go 1.16 resolve this? And what about using release branches if Go 1.16 doesn't resolve it?

[cryptix]

Now I'm confused. I thought you concern was about the diff conflicts in the generated code. The generated code is gone with 1.16.

Also I'm not proposing to commit the 3mb version ever so I'm not sure where conflicts would even come from.

[staltz]

Also, the prod style.css has to be regenerated sometimes depending on some changes in the templates (depending on what css classes are used).

[staltz]

Now I'm confused. I thought you concern was about the diff conflicts in the generated code. The generated code is gone with 1.16.

Also I'm not proposing to commit the 3mb version ever so I'm not sure where conflicts would even come from.

I was concerned about:

• Having to resolve git conflicts
• Making git reviews harder when there is generated code alongside source code
• Blurring the purpose of git, which is source code version control exclusively (I think I voiced this concern in that other thread), not distribution
  • E.g. we don't commit go binaries, thus the person checking out the git repo has to have Go installed. In general if someone wants to use a git repo, they need compilers installed, and Node.js can be considered one of those compilers that generate the style.css. The user of git is considered to be a developer with the appropriate tools, not the server ops admin

[cryptix]

I'd like to revisit this for the community release.

Again, my main want is: At the end of a PR we make sure the production version is checked in and up2date with the used classes in the templates.

I'd accompany this with a rule for the CI which rebuilds the file and complains if there is a diff.

[staltz]

The CI job is a good idea, would be interesting to see that running in practice. I think there are different solutions to this, though, and it would be good if (tailwind) developer experience is not impacted by the addition of manual steps, if we need to go back to doing styles again. For instance, maybe the CI job could build tailwind for production and commit after merging? There's also a possibility for a CI job to automatically push to a branch, that's something I do with ssb-keys-neon actually.

[cryptix]

tested my approach and somehow it produced diffs and errors when it shouldn't have.

Now looking into the auto push if changed but getting some weird errors when trying to push to the PR. https://github.com/github-actions-x/commit/issues doesn't look super cozy either.

[cryptix]

@staltz do you have insights in how this commit&push stuff works? I want it to push to the working branch but somehow it doesnt want to :-|

I see in your example it pushes to a different branch? but that seems like more hassle, too.

https://github.com/ssb-ngi-pointer/go-ssb-room/runs/2612773590

[cryptix]

I just found https://github.com/marketplace/actions/pr-branch-name , maybe that helps if GITHUB_REF doesn't work.

[staltz]

Good to go! Just remember to accept my commit suggestion :)