Documentation sites: prose and spell checkers (aspell, codespell, sphinx-lint, markdownlint via npm exec), VitePress, legacy GitBook, Read the Docs builds, plain-Markdown docs with a link checker

Ouverte
#280 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
python

Piste de recherche

Start with the documentation-site ecosystem detection in ecosystems/documentation.py, which currently lists only MkDocs, Sphinx, Docusaurus, mdBook, Hugo and Jekyll, and the static-analysis and link-check checks that consume it. Run the validator on a small fixture with a docs/.vitepress/config.ts and check the --map output. Done when VitePress is detected as a documentation site and the prose-checker and link-checker cases in the issue are credited or judged rather than skipped. The issue bundles several separate proposals, so agree the scope with a maintainer first.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

rust-lang/book runs aspell, mkdocs codespell and markdownlint-cli (via npm exec behind hatch), devguide sphinx-lint (the standard RST linter) and scikit-learn sphinx-lint + cython-lint → static-analysis FAIL "no static analyzer runs" for the site. vite's docs/ is a VitePress site (no Documentation site unit; link-check SKIP) and fastify runs two link checkers over its Markdown docs (link-check SKIP "not applicable to JavaScript"); cppbestpractices is a legacy GitBook (book.json + SUMMARY.md, "no recognised language"); bats-core's and flask's docs are built on Read the Docs (.readthedocs.yaml), not in CI.

Evidence from the corpus audit

rust-lang/book, mkdocs/mkdocs, python/devguide / static-analysis (prose and spell checkers)
  • kind: UNSUPPORTED
  • actual: FAIL "Documentation site: no static analyzer runs" (book, devguide); mkdocs: "markdownlint is configured
    (.markdownlint.yaml) but does not run".
  • expected: credit for the prose checkers these sites actually run: aspell (book), codespell (mkdocs), sphinx-lint
    (devguide, the standard RST linter); and markdownlint-cli via npm exec in mkdocs (hidden behind hatch, see below).
  • evidence: rust-lang/book .github/workflows/main.yml:92-93: - name: Spellcheck / run: bash ci/spellcheck.sh list (ci/spellcheck.sh runs aspell, exit 1 on a typo); mkdocs pyproject.toml:199: spelling = 'codespell mkdocs docs *.* ...', :200: markdown = "npm exec --yes -- markdownlint-cli README.md CONTRIBUTING.md docs/ ...";
    devguide .pre-commit-config.yaml:23-27: repo: https://github.com/sphinx-contrib/sphinx-lint ... id: sphinx-lint / args: [--enable=default-role] (read by the validator as a pre-commit.ci command: --facts shows
    "argv": ["sphinx-lint", "--enable=default-role"], but no tool claims it). docs/ecosystems/documentation.md
    lists only markdownlint and vale.
  • repro: .pre-commit-config.yaml with the sphinx-lint hook and ci: block, plus conf.py.
  • confidence: high
cpp-best-practices/cppbestpractices / detection (GitBook)
  • kind: UNSUPPORTED
  • actual: .map.json: "languages": [], ecosystems Data only; 30 checks SKIP "not applicable to a project of no
    recognised language".
  • expected: a Documentation site (legacy GitBook: book.json + SUMMARY.md), so link-check/static-analysis are at
    least asked (WARN).
  • evidence: book.json: "plugins": [ "github" ]; SUMMARY.md present; docs/ecosystems/documentation.md lists
    MkDocs, Sphinx, Docusaurus, mdBook, Hugo, Jekyll only.
  • repro: book.json + SUMMARY.md + README.md.
  • confidence: low (GitBook's open-source generator is dead; the repo is realistically "Markdown only")
vitejs/vite / detection (VitePress documentation site)
  • kind: UNSUPPORTED
  • actual: --map: no Documentation site ecosystem; link-check SKIP not applicable to JavaScript, Shell, TypeScript
  • expected: a documentation-site unit at docs/ (VitePress), as Docusaurus is detected for prettier.
  • evidence: docs/.vitepress/config.ts, docs/.vitepress/theme/, docs/package.json; package.json:36: "docs-build": "pnpm --filter=./docs run docs-build".
    Validator ecosystems/documentation.py:1-2: MkDocs, Sphinx, Docusaurus, mdBook, Hugo and Jekyll only. VitePress is the
    default site generator of the Vite/Vue ecosystem (vite, vitest, vue, pinia, vueuse, rollup).
  • repro: docs/.vitepress/config.ts + docs/index.md.
  • confidence: medium
fastify/fastify / link-check
  • kind: MESSAGE
  • actual: SKIP: not applicable to JavaScript, Shell, TypeScript
  • expected: PASS or at least a judged result: CI runs two link checkers over the Markdown documentation on every docs PR.
  • evidence: .github/workflows/links-check.yml: uses: lycheeverse/lychee-action@8646ba30535128ac92d33dfc9133794bfdd9b411 # 2.8.0 with fail: true and
    args: --offline --verbose --no-progress --root-dir "$(pwd)" './**/*.md'; then uses: JustinBeckwith/linkinator-action@7b6b0bc671f6264e1a8daa4488a5bd91ce61dcd4 # 2.4.2.
    docs/ is a plain Markdown tree (no generator config), so no "Documentation site" unit exists and the check is skipped even though the practice is present.
  • repro: docs/Guide.md + the lychee step above.
  • confidence: low (the check's scope is documentation sites; a Markdown docs/ tree may be out of scope by design)
open-telemetry/opentelemetry-proto / link-check
  • kind: UNSUPPORTED
  • actual: SKIP: not applicable to a project of no recognised language
  • expected: PASS (or at least applicable): CI runs lychee over the repository's Markdown documentation (docs/*.md, README.md) with a committed .lychee.toml, every push; the check only knows documentation sites (Sphinx, mdBook...), so plain Markdown docs plus lychee are invisible, and the SKIP reason ("no recognised language") is unrelated to what the check judges.
  • evidence: .github/workflows/build-check.yaml:161-162: - name: run markdown-link-check / run: make markdown-link-check; Makefile:172-181: LYCHEEIMAGE := $(shell awk '$$4=="lychee" {print $$2}' $(DEPENDENCIES_DOCKERFILE)) / docker run --rm ... $(LYCHEEIMAGE) --config home/repo/.lychee.toml --root-dir /home/repo -v home/repo; .lychee.toml:1: include_fragments = true.
  • repro: docs/index.md, .lychee.toml, workflow run: lychee --config .lychee.toml ..
  • confidence: low
asyncapi/spec, OAI/OpenAPI-Specification / static-analysis (markdownlint on specification prose)
  • kind: UNSUPPORTED
  • actual: FAIL static-analysis: JavaScript/TypeScript: no static analyzer runs; … with nothing said about the
    Markdown specification; markdownlint is only recognised for a Documentation-site unit (static-analysis hint
    markdownlint-cli2 … or vale), and neither repo has a site generator.
  • expected: a specification repository whose product is Markdown prose could be a documentation unit; both lint
    it in CI.
  • evidence: asyncapi/spec .github/workflows/lint.yml:16: run: docker run -v $PWD:/workdir ghcr.io/igorshubovych/markdownlint-cli:v0.35.0 "spec/asyncapi.md"; OAI .github/workflows/validate-markdown.yaml:31:
    run: yarn validate-markdown with .markdownlint.yaml and spec.markdownlint.yaml in the root
    (package.json:27: "validate-markdown": "oai-spec-validate-markdown").
  • repro: n/a
  • confidence: low

Found by the regression-corpus audit (235 real repositories, one or more per ecosystem profile; corpus and expected results in corpus/). Evidence is quoted from the audited checkouts at the commits pinned in corpus/projects.toml; <checkouts>/<owner>__<repo> is such a checkout.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt

Langage dominant
Python
Étoiles
4
Forks
1
Merge moyen
10 h 41 min
PR mergées (30 j)
79

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cpp-best-practices/project_validator

Toutes les issues de cpp-best-practices/project_validator

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.