Skip to content

refactor: use format to construct error in _tools/remark/plugins/remark-namespace-toc - #15127

Draft
Planeshifter wants to merge 1 commit into
developfrom
philipp/drift-tools-remark-plugins-2026-09-09
Draft

refactor: use format to construct error in _tools/remark/plugins/remark-namespace-toc#15127
Planeshifter wants to merge 1 commit into
developfrom
philipp/drift-tools-remark-plugins-2026-09-09

Conversation

@Planeshifter

Copy link
Copy Markdown
Member

Description

What is the purpose of this pull request?

This pull request:

  • normalizes error-message construction in _tools/remark/plugins/remark-namespace-toc to use @stdlib/string/format in place of string concatenation

remark-namespace-toc

The TOC transformer assembled its one thrown-error message via string concatenation, the lone deviation from the namespace convention. format is the error-construction idiom in 11 of the 12 error-constructing packages in _tools/remark/plugins (~92%). The message is now built with format, leaving the rendered text byte-for-byte identical. No observable behavior, signature, or test expectation changes.

Related Issues

Does this pull request have any related issues?

No.

Questions

Any questions for reviewers of this pull request?

No.

Other

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

Surfaced by an automated cross-package drift scan of the _tools/remark/plugins namespace. package.json shape, README sections, and the file tree are already uniform across the namespace, so no structural change is warranted; in particular, no package.json dependency edit is needed, since the namespace declares runtime dependencies as {} and requires @stdlib/string/format in code, per sibling convention.

Checklist

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

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 PR was produced by Claude Code (Opus 4.8) running an automated cross-package drift-detection routine. It extracted structural and semantic features across the namespace, identified the majority error-construction pattern, validated the single outlier through multiple independent review passes, and applied the mechanical, behavior-preserving fix.


@stdlib-js/reviewers

🤖 Generated with Claude Code

https://claude.ai/code/session_01DUP1buS4hqMNkdDbim1cNn


Generated by Claude Code

…emark-namespace-toc`

Normalize error-message construction in the TOC transformer to use
`@stdlib/string/format` in place of string concatenation, matching
the sibling convention in `_tools/remark/plugins`. `format` is the
error-construction idiom in 11 of the 12 error-constructing packages
in the namespace (~92%); `remark-namespace-toc` was the sole outlier.
The rendered message text is unchanged.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DUP1buS4hqMNkdDbim1cNn
@stdlib-bot stdlib-bot added the Tools Issue or pull request related to project tooling. label Sep 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Tools Issue or pull request related to project tooling.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants