Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • editors
  • open-analysis-update
  • 48-documentation-guide-on-credit
  • new-jekyll-setup
5 results
Search by author
  • Any Author
  • Alberto Lazari Alberto Lazari alazari
  • Anna Guttesen Anna Guttesen nnm329
  • Bernd Taschler Bernd Taschler ndcn1032
  • Cassandra Gould van Praag Cassandra Gould van Praag cassag
  • David Flitney David Flitney flitney
  • Duncan Mortimer Duncan Mortimer duncan
  • Duncan Smith Duncan Smith dsmith
  • Evan Edmond Evan Edmond edmond
  • Fidel Alfaro Almagro Fidel Alfaro Almagro falmagro
  • Gaurav Bhalerao Gaurav Bhalerao mcz502
  • Juju Fars Juju Fars pfr545
  • Kirralise Hansford Kirralise Hansford bcy376
  • Lara Nikel Lara Nikel lara.nikel
  • Laurence Hunt Laurence Hunt lhunt
  • Lilian Weber Lilian Weber psyc1406
  • Lisa Spiering Lisa Spiering wym003
  • Ludovica Griffanti Ludovica Griffanti ludovica
  • Luke Baxter Luke Baxter lbaxter
  • Marieke Martens Marieke Martens mmartens
  • Mark Jenkinson Mark Jenkinson mark
20 authors
  1. Jan 16, 2023
  3. Jan 09, 2023
  5. Dec 29, 2022
  7. Dec 08, 2022
  9. Dec 05, 2022
  11. Nov 23, 2022
  13. Nov 15, 2022
  15. Nov 05, 2022
  17. Oct 25, 2022
  19. Oct 17, 2022
  21. Sep 29, 2022
  23. Sep 22, 2022
  25. Sep 19, 2022
  27. Aug 23, 2022
  29. Aug 13, 2022
  31. Aug 12, 2022
  33. Jul 25, 2022
    • Matt Wang's avatar
      Update Stylelint to v14, extend SCSS plugins, remove primer-* configs, resolve issues (#821) · c2ec3d89
      Matt Wang authored 
      This is a catch-all PR that modernizes and updates our Stylelint config, and resolves all open issues. This is a pretty big change - so I want to update all of our related dependencies in lockstep.

In particular, this PR

- [x] updates stylelint to `v14`
- [x] adds in the standard stylelint config for SCSS (`stylelint-config-standard-scss`)
- [x] swaps out `stylelint-config-prettier` for `stylelint-config-prettier-scss`
- [x] ~~properly update `@primer`-related plugins:~~ completely remove `primer` from our configuration
- [x] autofix, manually resolve, or disable all newly-introduced lint errors; **I've avoided manually resolving errors that would be a behavioural change**
- [x] re-runs `npm run format`

See the "next steps" section on some extra thoughts on disabling errors.

(implicitly, I'm also using node 16/the new package-lock format).

### disabling rules and next steps

I've introduced several new disabled rules. Let me quickly explain what's going on; there are two categories of rules I've disabled:

1. rules that were temporary disables; they were frequent enough that I couldn't manually resolve them, but should be simple. **I plan on opening issues to re-enable each of these rules**, just after this PR
    - `declaration-block-no-redundant-longhand-properties`: this is just tedious and error-prone
    - `no-descending-specificity`: this one is tricky since it could have impacts on the cascade (though that seems unlikely)
    - `scss/no-global-function-names`: I think we need to [import map and then use `map.get`](https://stackoverflow.com/questions/64210390/sass-map-get-doesnt-work-map-get-does-what-gives), but I'll leave this as out of scope for now
2. rules that are long-term disables; due to the SASS-based nature of our theme, I think we'll keep these in limbo
    - `alpha-value-notation` causes problems with SASS using the `modern` syntax - literals like `50%` are not properly interpolated, and they cause formatting issues on the site
    - `color-function-notation` also causes problems with SASS, but in this case the `modern` syntax breaks SASS compilation; we're not alone (see this [SO post](https://stackoverflow.com/questions/71805735/error-function-rgb-is-missing-argument-green-in-sass)). 

In addition, we have many inline `stylelint-disable` comments. I'd open a separate issue to audit them, especially since I think some disables are unnecessary.

### on Primer 

**note: there hasn't been much other discussion, so I'm going to remove primer's stylelint config.**

If I do add `@primer/stylelint-config`, I get *a ton* of errors about now using `@primer`'s in-built SCSS variables. I imagine that we probably won't want to use these presets (though I could be wrong). In that case, I think we could either:

1. disable all of those rules
4. not use `@primer/stylelint-config`, since we're not actually using primer, and shift back to the standard SCSS config provided by Stylelint

~~Any thoughts here? I also don't have the original context as to why we do use the primer rules, perhaps @pmarsceill can chime in?~~
      Unverified
      c2ec3d89
  35. Jul 04, 2022
  37. Jun 23, 2022
  39. Apr 18, 2022
  41. Mar 09, 2022
  43. Mar 08, 2022
  45. Mar 03, 2022
  47. May 07, 2021
  49. Mar 29, 2021
  51. Oct 03, 2020
  53. Sep 26, 2020
  55. Sep 22, 2020
  57. Sep 16, 2020
  59. Sep 12, 2020
  61. Aug 26, 2020
  63. Aug 05, 2020
  65. Jul 21, 2020
  67. Jul 15, 2020
  69. Jun 26, 2020