A couple of changes to prep for v0.4.0-rc1:
- bump the version
- add myself to the authors + email (this is primarily so that Patrick doesn't get siloed as the only maintainer; if you'd like to be added @just-the-docs/maintainers, let me know!)
- adds some more metadata ([gemspec docs](https://guides.rubygems.org/specification-reference/#metadata))
- updated the path to also include the CHANGELOG and favicon in the gem bundle
This PR has a bit of scope creep! This PR now:
- changes the mermaid opt-in logic to only check for the existence of a `mermaid` key instead of `mermaid != false`: this resolves the follow-up in #857
- changes the behaviour of mermaid configuration
- instead of using `mermaid_init.html` with default settings, makes the include `mermaid_config.js`
- the include is loaded directly into the contents of `mermaid_initialize`
- by default, it is an empty object (i.e. `{}`), triggering the defaults
- updates docs
- adds an example to the markdown kitchen sink
It does significantly change the interface provided in #857, and I apologize for the confusion. However, given the discussion in this PR, I think it's the best move forward!
The nav scroll feature had stopped working (altogether),
due to the change from absolute to relative urls.
This update uses the document location pathname as the `href`.
It appears to work locally.
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?~~
- add an extra filter to children-list to fix#854
- strengthen condition for assignment to first_level_url
Tested with Jekyll 3.9.2 and 4.2.2
Note: Jekyll 3.9.2 doesn't support `| where: "grand_parent: nil"`
This is a PR with three key changes:
1. Consolidate two identical CI files, `ci.yml` and `ci-master.yml` into one file
2. Consolidate two almost-identical jobs (`jekyll-build-*`) into one job with a strategy matrix
3. Update various dependencies/platforms
* Node: `12.x` -> `16.x` (only in CI); `12.x` has been EOL for a while
* Ruby: `2.6` -> `2.7`; `2.6` just reached EOL
* `actions/checkout` -> `v2` -> `v3`
* switches `jekyll/builder` to `jekyll/jekyll`, since we don't actually use any of the features in `jekyll/builder`
## on our CI philosophy
In working on this, I have a couple of questions:
1. We don't actually use our `Dockerfile` that we provide. Does this make sense? Should we be running CI with this instead?
2. Is there a specific reason that we're using `jekyll/jekyll`? Notably, this isn't an official package, but a community-driven one. Does it match what's used by GitHub Pages?
3. Do we have to use any docker image at all? For example, what if we just rely on the `setup-ruby` action?
* one advantage of this is that it's much easier for us to test across multiple OS versions; we just need to have a strategy matrix for OS and do windows, macos, ubuntu, etc.
* another advantage is that we can easily test different ruby versions in conjunction with different jekyll versions
Eventually, I would like to see us test across:
* different Jekyll versions
* different OSes
* different Ruby versions
but perhaps that might be too aggressive. Happy for any feedback on this PR or those questions!
I have a site whose content is written in AsciiDoc, using the [jekyll-asciidoc][] plugin.
Just the Docs works great, but there are just two minor styling glitches I've noticed:
The first is that Just the Docs' CSS doesn't understand the code block markup jekyll-asciidoc produces. It's not too different though, so it's very easily fixed.
The second is that jekyll-asciidoc generates `div.sect(𝑛 − 1)` elements around headings of type `h𝑛`, that enclose all the heading and all the content after it until the next heading of greater or equal rank.
This means that headings are _always_ first children in AsciiDoc output, which meant the wrong margins were applied to most headings. To fix this, we need to only reduce the margin of first-child headings nested directly below the .main-content element, and headings nested directly below AsciiDoc `.sect𝑛` elements that are themselves first children.
With these two small changes, my site looks perfect, and the styles look exactly the same as on Just the Docs' own documentation.
[jekyll-asciidoc]: https://github.com/asciidoctor/jekyll-asciidoc
