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

Aperta
#280 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
Python
Stelle
4
Fork
1
Merge medio
10h 41m
PR unite (30g)
79

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di cpp-best-practices/project_validator

Tutte le issue di cpp-best-practices/project_validator

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.