OBS-383: Replace LESS with native CSS

[toufali]

This PR transpiles LESS files to CSS – a preliminary step for the front-end refactor.

The following is covered:
OBS-388: transpile LESS files to CSS

OBS-389: introduce CSS custom properties – transpiling replaced LESS vars with hard-coded values. This step pulls those values back out into CSS custom properties (vars).

OBS-391: Remove the LESS compiler and all associated code – also removes all .less files and tools used to transpile.

These changes should not result in any visible difference in-browser. The app should still build without issue using django-pipeline. This was tested by following the steps in Production-style Assets, then spot-testing the site in the browser.

Note that django-pipeline is unable to process CSS @import rules. Consequently, this PR uses a single stylesheet (webapp/crashstats/crashstats/static/crashstats/css/base.css) with @imports resolved inline. This is temporary – when we introduce a capable build tool, we should delete the inlined styles and revert to @import individual stylesheets for better developer experience/organization. Additional details/breadcrumbs commented in base.css.

[smarnach]

I'm somewhat out of my comfort zone here, so I'm not sure I understand correctly what's going on here.

It looks like this PR adds compiled versions of all the less files. And it looks like in the compiled versions all imports are inlined, and all variables are replaced with their actual values.

What I believe we eventually want is using CSS imports instead of the less imports, and CSS variables instead of the less variables, since this would keep the logical structure and maintainability of the code. Is this what you are trying to do? Or are you going some other route?

[toufali]

I'm somewhat out of my comfort zone here, so I'm not sure I understand correctly what's going on here.

It looks like this PR adds compiled versions of all the less files. And it looks like in the compiled versions all imports are inlined, and all variables are replaced with their actual values.

What I believe we eventually want is using CSS imports instead of the less imports,

Yes! Unfortunately CSS @import is not supported by django-pipeline. I plan to add that functionality after we install a new build tool to take django-pipeline's place. With the new tool (to come under separate PR), we should be able to fully utilize @import with tree-shaking and logical code maintainability. I left the soon-to-be obsolete LESS files in place as a temporary reference to the imports.

and CSS variables instead of the less variables,

Yes, ideally we would use CSS variables. However, the entire site style is ripe for a facelift. As I understand, the colors assigned to most/all variables are based on an obsolete "Photon" color palate. I'm happy to take a slight detour to replace all LESS vars with CSS vars, but I wonder if the app would be better served with a deeper look at style. Also, the LESS compiler doesn't offer automatic variable conversion, so the variable work would need to be manual.

In defining scope, I decided to focus more on build-tooling, architecture, dependencies, etc, leaving facelifts for future tasks. (Related, jQuery should be replaced too, but also probably out of scope for this first pass.) I intended this refactor to have a light touch on script/style, in order to confirm everything still works as expected with new tooling in place.

Happy to continue this discussion if you feel we should spend more time on CSS vars as condition for migration!

[willkg]

@smarnach I didn't realize you assigned this to yourself last week. Can you assign the review of this to me? I'm working with @toufali on this project and have a plan for validation already.

[smarnach]

@willkg Sure, I didn't mean to interfere.

[toufali]

@smarnach I appreciated hearing your thoughts! Thanks for the look 😎

[willkg]

This PR doesn't remove LESS files, the compiler, related settings, and such. I wanted to make sure that building the image works correctly and the site serves the bundled CSS files correctly without the LESS files. Thus I pulled the changes down, rebased against current main tip, removed all the LESS files, and verified that the image builds correctly and the site works correctly.

Everything looks good. The only two changes to make are:

1. remove the less-to-css shell script since we won't need to use it beyond this PR
2. fix the commit comment to match our conventions:
   https://socorro.readthedocs.io/en/latest/dev.html#git-conventions

[willkg]

It's super helpful to know how these files were converted--thank you!

However, I think it would be better to put this code in a gist or in the PR description, but not include it in the PR. This is a script we're only using for these changes and won't be using further so we don't want to maintain it.

[willkg]

Because we're not going to have any less files after this PR lands, we don't need to add the script entrypoint.

[toufali]

Thanks @willkg for the review! Agreed on all.

I intended the LESS script-associated code to only exist within commit history, removing them in the second commit (along with .less files). This assumes we're not using the "squash" merge strategy 😉

[willkg]

@toufali Can you rebase this against main tip to pick up changes to obs-common and Socorro over the last couple of weeks?

[willkg]

I read through the last two commits. I ran through the site in my local dev environment. Everything looks good! 💯