Markdownlint should instead run after Liquid parsing
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- jekyll
- Área
- build-system, documentation
Línea de trabajo
Comienza rastreando el proceso de compilación de Jekyll y la invocación actual de markdownlint, ya que no se mencionan archivos ni pruebas específicos. Comprueba cómo podrían emitirse documentos formateados después del análisis de Liquid y, a continuación, verifica que markdownlint gestione correctamente los casos indicados de énfasis, mayúsculas y minúsculas y enlaces de Liquid.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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
- Our usage of underscores in path names for
- 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 %}
- E.g.
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.
- Lenguaje dominante
- HTML
- Estrellas
- 40
- Forks
- 10
- Merge medio
- 32 min
- PR fusionados (30 d)
- 4
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de OpenTabletDriver/opentabletdriver.github.io
-
wiki
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
-
enhancement good first issue wiki
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
bug wiki
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
OpenTabletDriver/opentabletdriver.github.io#302 · 1 comentario ·
-
enhancement wiki
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
OpenTabletDriver/opentabletdriver.github.io#299 · 2 comentarios ·
Todos los issues de OpenTabletDriver/opentabletdriver.github.io
Issues similares
-
area/install-update comp/cli duplicate P2 python:uv sweeper:risk-compatibility type/bug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 62/100
NousResearch/hermes-agent#135440 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
pytorch/tensordict#1927 ·
Los mantenedores suelen responder en 1 día
-
bug ticket
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
cratestack/cratestack#1154 ·
Los mantenedores suelen responder en 1 día
-
dependencies java
Dificultad 1/5 Menos de una hora Aptitud para principiantes 62/100
micrometer-metrics/tracing#1588 ·
Los mantenedores suelen responder en 1 día
-
status:needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día