build: separate lint task package READMEs and /docs .md files

[batpigandme]

Dedicated Remark configuration for Markdown files in package directories and the docs directory and update the pre-commit hook to run separate linting tasks for package and non-package files.

Assisted-by: Calude-Opus-4-6

---

type: pre_commit_static_analysis_report
description: Results of running static analysis checks when committing changes. report:

• task: lint_filenames status: passed
• task: lint_editorconfig status: passed
• task: lint_markdown status: na
• task: lint_package_json status: na
• task: lint_repl_help status: na
• task: lint_javascript_src status: passed
• task: lint_javascript_cli status: na
• task: lint_javascript_examples status: na
• task: lint_javascript_tests status: na
• task: lint_javascript_benchmarks status: na
• task: lint_python status: na
• task: lint_r status: na
• task: lint_c_src status: na
• task: lint_c_examples status: na
• task: lint_c_benchmarks status: na
• task: lint_c_tests_fixtures status: na
• task: lint_shell status: missing_dependencies
• task: lint_typescript_declarations status: passed
• task: lint_typescript_tests status: na
• task: lint_license_headers status: passed ---

Resolves #11121

Description

What is the purpose of this pull request?

This pull request:

This PR adds separate remark lint configurations for package READMEs, /docs Markdown files, and general Markdown files. Previously, all Markdown files were linted with the same remark config, which meant rules specific to package READMEs (like remark-lint-expected-html-sections and remark-lint-html-section-structure) were applied to files where they don't belong (e.g., files in /docs).

Remark configurations:

• .remarkrc.js — default config for general Markdown files (no HTML section rules)
• .remarkrc.pkg-readmes.js — package READMEs (includes HTML section rules)
• .remarkrc.docs.js — documentation files (no HTML section rules, separate for future customization)

New Make targets:

Linting:

• make lint-markdown-package-readmes — lint all package READMEs
• make lint-markdown-package-readme-files FILES='...' — lint a specified list of package READMEs
• make lint-markdown-docs — lint all documentation Markdown files
• make lint-markdown-docs-files FILES='...' — lint a specified list of documentation files
• make lint-markdown / make lint-markdown-files — lint general Markdown (unchanged targets, now uses default config)

Listing:

• make list-markdown-pkg-readmes — list all package README files (now defined in ls/markdown/pkg_readmes.mk)
• make list-markdown-docs — list all documentation Markdown files (now defined in ls/markdown/docs.mk)

All targets support filter patterns, e.g.:

make lint-markdown-package-readmes MARKDOWN_PKG_READMES_FILTER=".*/math/base/special/abs/.*"
make list-markdown-docs MARKDOWN_DOCS_FILTER=".*/contributing/.*"

Pre-commit hook now splits changed Markdown files into three categories and lints each with the appropriate config.

Related Issues

Does this pull request have any related issues?

This pull request has the following related issues:

• [RFC]: Apply a subset of remark rules/plugins to files in /docs #11121 etc/remark/.remarkrc.js

Questions

Any questions for reviewers of this pull request?

I realize it's a bit weird that we're loading the plugins list for docs for the general remarkrc. We don't need to do the HTML section linting for non-package-README files, though. The reason for having three targets is because we might want to do separate processing for /docs files in the future. Currently it's the same config as "everything else".

https://github.com/stdlib-js/stdlib/pull/11139/changes#diff-e7ff32f40f118b3274e48d9933d7c636c4d7cb9788b6d6dcf25a370631567b91

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

AI Assistance

When authoring the changes proposed in this PR, did you use any kind of AI assistance?

• Yes
• No

If you answered "yes" above, how did you use AI assistance?

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

Disclosure

If you answered "yes" to using AI assistance, please provide a short disclosure indicating how you used AI assistance. This helps reviewers determine how much scrutiny to apply when reviewing your contribution. Example disclosures: "This PR was written primarily by Claude Code." or "I consulted ChatGPT to understand the codebase, but the proposed changes were fully authored manually by myself.".

Used for understanding the current remark build and for generating new make setup (all of which I read and reviewed).

---

@stdlib-js/reviewers

[batpigandme]

/stdlib merge

[batpigandme]

@kgryte Per our discussion yesterday, I've separated out package READMEs and docs (although docs rules apply to everything not in the package READMEs, it makes sense to have a separate config for future editing). I've updated the PR description above to reflect the changes.

The find variables and list targets are now in tools/make/lib/ls/markdown/:

• pkg_readmes.mk — FIND_MARKDOWN_PKG_READMES_CMD, MARKDOWN_PKG_READMES_FILES, list-markdown-pkg-readmes
• docs.mk — FIND_MARKDOWN_DOCS_CMD, MARKDOWN_DOCS_FILES, list-markdown-docs
• files.mk — existing FIND_MARKDOWN_CMD, MARKDOWN_FILES, list-markdown-files

[batpigandme]

/stdlib merge

[kgryte]

Check naming conventions as discussed during 1:1.

[kgryte]

Just to clarify, this is intentional? Meaning, for other Markdown files, we want to use list of plugins used for docs?

That is possible, if we assume that the docs config is effectively a subset of all the plugins we want to apply.

[batpigandme]

Yes. So this was a question I brought up in #11121 (comment).

My question is whether we want to apply the full set of plugins/default REMARK_CONF to all markdown files EXCEPT those in /docs, or if we want to apply the full plugins set ONLY to those files matching lib/node_modules/@stdlib/.

By default, remark uses all of the plugins in the plugins subfolder (which includes linters and processors). Because these plugins were designed to work with the very structured package READMEs, this includes things like linting for the expected HTML sections.

So, you're right, the /docs config is just applying a subset. Right now we're basically saying "if it's not a package README, don't expect the HTML sections to be there" (we went even stricter than my original proposal where everything in lib/node_modules/@stdlib would get the full processing).

I definitely think it's weird (and unintuitive) to have the /docs setup be, effectively, the default. But, we also don't expect those HTML sections in the root documentation.

We could do a rename, or we could not use /docs as the default.

We already have them in three buckets (package READMEs, docs, and other), so it's easy enough to do (it's just that "other" currently gets the same treatment as docs).

[batpigandme]

Dug into the transformer plugins (equations, namespace-toc, related, pkg-urls, stdlib-urls). None of them actually load via .remarkrc.*— each recipe attaches them via --use flags. So, they only ever touch package READMEs (7,291 READMEs have <equation> tags; zero non-READMEs do; the other recipes scope explicitly to READMEs via find ... -name 'README.md' or list-pkgs-namespace-readmes).

So .remarkrc.js-as-docs-subset doesn't route through any transformer plugin. The design question is purely about lint ergonomics for non-README, non-/docs markdown.

[kgryte]

My guess is that since we are mucking with lint recipes, we'll also need to update various workflow files. E.g.,

• stdlib/.github/workflows/lint_changed_files.yml

  Line 147 in 42acdf2

  - name: 'Lint Markdown files'

• stdlib/.github/workflows/lint_random_files.yml

  Line 255 in 42acdf2

  make lint-markdown-files FAST_FAIL=0 FILES="${files}"

And there may be more.

If we merge this as is, our CI will start behaving differently, so we should make sure that it behaves as intended.

[batpigandme]

My guess is that since we are mucking with lint recipes, we'll also need to update various workflow files...
And there may be more.

Swept .github/workflows/:

• lint_changed_files.yml:147 and lint_random_files.yml:255 - used three-bucket partition (pkg READMEs / /docs / other) mirroring the pre-commit hook's classification from 8a49ffd, so local and CI route files through the same configs.
• markdown_pkg_urls.yml:125 - markdown-pkg-urls is URL rewriting, not lint. Unaffected.
• scripts/common/task_runner:225 - # make lint-markdown is commented out. Flagging but left alone.

One judgment call: lint_changed_files.yml kept its existing \.github/workflows/.*\.md$ exclusion (moved to the "other" bucket to match the hook); lint_random_files.yml didn't have the exclusion, and I didn't add it. LMK if you'd rather I unify them.

[batpigandme]

I've done a refactor using the base convention we (@kgryte and I) discussed in our 1:1.

Overview:

etc/remark/
  .remarkrc.js              → plugins/base.js         (68 plugins)
  .remarkrc.docs.js         → plugins/docs.js         (= base, 68)
  .remarkrc.pkg_readmes.js  → plugins/pkg_readmes.js  (base + 2 HTML, 70)
  plugins/
    base.js          ← NEW (the 5 universal blocks)
    docs.js          ← rewritten as thin wrapper: `require('./base')`
    pkg_readmes.js   ← NEW (base + HTML-section lints)
    index.js         ← DELETED
    [subdirs unchanged]

I've matched the idiom used in the (now) base.js (formerly index.js).

var plugins = [];

plugins.push( require( './frontmatter' ) );
plugins = plugins.concat( require( './lint' ) );
plugins.push( require( './eslint' ) );
...

for pkg_readmes.js

var plugins = [];

plugins = plugins.concat( require( './base' ) );
plugins.push( require( './lint-expected-html-sections' ) );
plugins.push( require( './lint-html-section-structure' ) );

Yesterday, you'd mentioned using slice(), which would be:

var plugins = require( './base' ).slice();
plugins.push( require( './lint-expected-html-sections' ) );
plugins.push( require( './lint-html-section-structure' ) );

If you'd prefer that, just let me know.