search

UBCCM / UBC-DEF

University of British Columbia Digital Experience Framework (previously known as UBC-CLF)
MIT License
3 stars 4 forks source link

Include CSS linter #44

Closed occupant closed 5 years ago

occupant commented 5 years ago

Problem As part of a modern shared web dev toolchain, a linter is a critical tool for maintaining CSS consistency and cleanliness. It can help identify and prevent common issues from moving into production code, as well as make the code more readable.

Proposed solution
There are number of packages we could consider. The most commonly used are listed on npm trends.

I suggest using stylelint for now, as it is very well maintained, has a well-established community with pre-built configurations that can be extended as needed. Additionally, unlike a tool like sass-lint that simply reports errors, there is a flag that can automatically fix most errors. This can be done within many filetypes (sass, less, css, js, etc), although some require postcss.

A sample config file.

Alternatives Considered
Previously we considered sass-lint, however this package is currently unmaintained.

clean-css currently has more downloads and looks to be very well used, however I'm admittedly not as familiar with it. It looks to be very flexible, however I haven't come across something similar to the shared configurations (meaning we manage more). Totally open to discussing this though.

hazuremon commented 5 years ago

Definitely, we need this as part of the CI. I would suggest tying this to the code review process as part of the automated QA process.

For rules in the sample config file, is this your proposed config or just as a sample?

occupant commented 5 years ago

The sample config is what I've been using and I think it's a good place to start. It first includes stylelint-config-standard (a boilerplate for common stylistic standards) and stylelint-config-rational-order (which corresponds pretty well to the sort ordering we have discussed and agreed upon previously).

Then there are a few rules for our specific config. Assuming we use tailwind, I've ok'd the @responsive rule with

at-rule-no-unknown": [true, {
            "ignoreAtRules": ["responsive"]
        }],

etc.

We can go through them one by one if needed and adjust where necessary.