Markdownlint should instead run after Liquid parsing

Offen
  • Stimmt etwas nicht?
#126 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 2 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
jekyll
Bereich
build-system, documentation

Rechercherichtung

Beginne damit, den Jekyll-Build-Prozess und den aktuellen Aufruf von markdownlint nachzuverfolgen, da keine spezifischen Dateien oder Tests genannt sind. Prüfe, wie formatierte Dokumente nach dem Parsen von Liquid ausgegeben werden könnten, und verifiziere anschließend, dass markdownlint die aufgeführten Fälle für Hervorhebung, Groß-/Kleinschreibung und Liquid-Links korrekt verarbeitet.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug ci meta

A lot of the markdownlint functionality is hampered because of Liquid tags

  • MD037 (Spaces inside emphasis markers) is disabled because of it
    • Our usage of underscores in path names for {% link %}s makes this rule parse incorrectly
  • MD044 (Names should have correct capitalization)
    • Same issue as with MD037, it recognizes Liquid tags as explicit text.
  • Reference links that are pointing to Liquid tags are not checked for link validity
    • E.g. [My link] with [Mylink]: {% link _sections.Tablets.md %}

While some of these issues are less of an issue with our HTML linting in place, there are other issues that cannot easily be worked around.

The best solution is as the title proposes, to extract the Markdown documents after the Liquid tags have been parsed so that markdownlint can correctly parse the documents as it expects. This is likely achieved by outputting the formatted documents as part of the Jekyll build process.

Vorherrschende Sprache
HTML
Sterne
42
Forks
10
Ø Merge
2 T. 8 Std.
Gemergte PRs (30 T.)
6

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus OpenTabletDriver/opentabletdriver.github.io

Alle Issues in OpenTabletDriver/opentabletdriver.github.io

Ähnliche Issues

Weitere Issues zu Build System

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.