#markdownlint — Public Fediverse posts

Линтеры вне кода: как HTML, Markdown и YAML становятся предсказуемыми

Когда я прихожу в новый проект и провожу аудит, почти всегда вижу одну и ту же картину. Код аккуратный, линтеры строгие, CI настроен. Но стоит открыть разметку или конфиги — и начинается творческий беспорядок. Кто-то форматирует по одному, кто-то по другому, кто-то копирует куски из StackOverflow, не особо понимая синтаксис. Получается парадокс: мы защищаем самую очевидную часть системы и игнорируем инфраструктуру, документацию и шаблоны. Хотя по факту это такие же контракты проекта, просто записанные не на языке программирования, а на языках разметки. Со временем я перестал разделять «код» и «не код». Если файл участвует в работе продукта — он должен быть проверяемым. Автоматически. Без надежды на внимательность разработчика. В данной статье я покажу, как именно это выглядит на практике и какие инструменты я использую каждый день.

https://habr.com/ru/articles/1001496/

#линтеры #git_hooks #htmlhint #markdownlint #yamllint #проверка_кода #ci #качество_кода #контроль_качества #code_style

Линтеры вне кода: как HTML, Markdown и YAML становятся предсказуемыми

Когда я прихожу в новый проект и провожу аудит, почти всегда вижу одну и ту же картину. Код аккуратный, линтеры строгие, CI настроен. Но стоит открыть разметку или конфиги — и начинается творческий беспорядок. Кто-то форматирует по одному, кто-то по другому, кто-то копирует куски из StackOverflow, не особо понимая синтаксис. Получается парадокс: мы защищаем самую очевидную часть системы и игнорируем инфраструктуру, документацию и шаблоны. Хотя по факту это такие же контракты проекта, просто записанные не на языке программирования, а на языках разметки. Со временем я перестал разделять «код» и «не код». Если файл участвует в работе продукта — он должен быть проверяемым. Автоматически. Без надежды на внимательность разработчика. В данной статье я покажу, как именно это выглядит на практике и какие инструменты я использую каждый день.

https://habr.com/ru/articles/1001496/

#линтеры #git_hooks #htmlhint #markdownlint #yamllint #проверка_кода #ci #качество_кода #контроль_качества #code_style

Линтеры вне кода: как HTML, Markdown и YAML становятся предсказуемыми

Когда я прихожу в новый проект и провожу аудит, почти всегда вижу одну и ту же картину. Код аккуратный, линтеры строгие, CI настроен. Но стоит открыть разметку или конфиги — и начинается творческий беспорядок. Кто-то форматирует по одному, кто-то по другому, кто-то копирует куски из StackOverflow, не особо понимая синтаксис. Получается парадокс: мы защищаем самую очевидную часть системы и игнорируем инфраструктуру, документацию и шаблоны. Хотя по факту это такие же контракты проекта, просто записанные не на языке программирования, а на языках разметки. Со временем я перестал разделять «код» и «не код». Если файл участвует в работе продукта — он должен быть проверяемым. Автоматически. Без надежды на внимательность разработчика. В данной статье я покажу, как именно это выглядит на практике и какие инструменты я использую каждый день.

https://habr.com/ru/articles/1001496/

#линтеры #git_hooks #htmlhint #markdownlint #yamllint #проверка_кода #ci #качество_кода #контроль_качества #code_style

Линтеры вне кода: как HTML, Markdown и YAML становятся предсказуемыми

Когда я прихожу в новый проект и провожу аудит, почти всегда вижу одну и ту же картину. Код аккуратный, линтеры строгие, CI настроен. Но стоит открыть разметку или конфиги — и начинается творческий беспорядок. Кто-то форматирует по одному, кто-то по другому, кто-то копирует куски из StackOverflow, не особо понимая синтаксис. Получается парадокс: мы защищаем самую очевидную часть системы и игнорируем инфраструктуру, документацию и шаблоны. Хотя по факту это такие же контракты проекта, просто записанные не на языке программирования, а на языках разметки. Со временем я перестал разделять «код» и «не код». Если файл участвует в работе продукта — он должен быть проверяемым. Автоматически. Без надежды на внимательность разработчика. В данной статье я покажу, как именно это выглядит на практике и какие инструменты я использую каждый день.

https://habr.com/ru/articles/1001496/

#линтеры #git_hooks #htmlhint #markdownlint #yamllint #проверка_кода #ci #качество_кода #контроль_качества #code_style

I find myself constantly making mistakes when it comes to writing markdown files. I mostly use markdown for creating little notes to myself, so any simple tool is good enough for me. I started to search for some command line tool that I can use to check the syntax for me. I think this very simple to use program "markdownlint" is a good one. 😁

https://github.com/markdownlint/markdownlint

#cli #markdownlint #markdown #lint

I'm so grateful for #markdownlint having an option to automatically fix a bunch of errors.

Doing #markdown #validation on a folder within the #handbook and it had 1805 errors, but after the auto-fixing, there are 420 errors.

Trying out #markdownlint on the #Regal docs, and I rather like it! Well done @DavidAnson and contributors 👏

It's a liitle pedantic, but that's a sensible default for a linter. Plenty of configuration options, which is nice. One thing I can't figure out is whether it's possible to disable a rule for just a single file. I have one file where "fixing" a rule isn't doable for... reasons. I still want to include the rule for all other files though.

@cwoodruff Citing #Emacs might start editor wars, so I'll instead just say #VSCode and #markdownlint extension and VS Code Preview.

Updated: #markdownlint v0.28.0, #Markdown #linting library for #NodeJS

- Introduce `micromark` parser for better positional data (internal only)
- Use `micromark` in MD013/MD033/MD034/MD035/MD038/MD044/MD052/MD053
- Simplify file-based test cases
- Unify browser script for demo
- Update dependencies

https://github.com/DavidAnson/markdownlint