chore: add missing field

[Planeshifter]

Description

What is the purpose of this pull request?

This pull request:

• Adds the missing top-level os field to the package.json of _tools/eslint/rules/no-builtin-big-int, _tools/eslint/rules/no-error-string-concat, _tools/eslint/rules/no-new-array, and _tools/eslint/rules/tsdoc-declarations-doctest, the only four members of the namespace lacking it.

The inserted value is the complete operating-system enum declared in _tools/package-json/schema/lib/schema.json, and the key is positioned between engines and keywords per the canonical ordering in _tools/package-json/standardize/lib/keys.json. The change is purely additive (44 insertions, 0 deletions) and touches no other keys.

Namespace summary

• Members analyzed: 125 (direct children of lib/node_modules/@stdlib/_tools/eslint/rules/ containing a package.json).
• Features analyzed: 12 — file tree, package.json top-level key set, scripts key set, stdlib key set, README section list and order, test/benchmark/example file naming, require() dependency set, exported-value kind, argument-validation prologue, error-message construction, and the JSDoc shape of each rule's create function.
• Features with a clear majority (≥75%): 9. Conformance was total (100%) on lib/index.js, lib/main.js, examples/index.js, test/test.js, test/fixtures/valid.js, test/fixtures/invalid.js, the 16 always-present package.json keys, empty dependencies/devDependencies, and the ## Usage / ## Examples README sections. The os key was the only clear-majority feature whose outliers yielded a mechanical, behavior-preserving correction.
• Features without a clear majority (excluded): 3 — README section order beyond ## Usage / ## Examples (## Notes appears in 7/125, 5.6%); scripts and stdlib key sets (scripts is {} in all 125, so there are no keys to vote on); and the JSDoc @param list of internal helper functions, which tracks each rule's own complexity and carries no namespace-wide convention.

_tools/eslint/rules/no-builtin-big-int

_tools/eslint/rules/no-builtin-big-int implements a pure AST-based ESLint rule: it walks Literal and CallExpression nodes to flag the built-in BigInt literal syntax and constructor in favor of @stdlib/bigint/ctor. No native bindings, no platform branching, nothing that ties it to a specific OS. We add the missing os field between engines and keywords, matching the canonical ordering in _tools/package-json/standardize/lib/keys.json and bringing it in line with 121/125 (96.8%) sibling _tools/eslint/rules packages and 6127/6225 (98.4%) package.json files project-wide.

_tools/eslint/rules/no-error-string-concat

_tools/eslint/rules/no-error-string-concat implements a pure AST check flagging + concatenation in error constructor arguments; it has no native bindings, no OS branching, nothing platform-specific. Adding os brings it in line with 121 of 125 sibling rule packages (96.8%) and 6127 of 6225 package.json files project-wide (98.4%), inserted between engines and keywords per the canonical ordering in _tools/package-json/standardize/lib/keys.json.

_tools/eslint/rules/no-new-array

_tools/eslint/rules/no-new-array was missing the top-level os field; added it between engines and keywords per the canonical key ordering in _tools/package-json/standardize/lib/keys.json, with the full operating-system enum from _tools/package-json/schema. The rule's implementation is a pure AST check flagging new Array() expressions in favor of array literals — no native bindings, no platform-conditional logic — so it runs identically on every supported OS and has no basis for omitting the field. 121 of 125 sibling packages under _tools/eslint/rules (96.8%) already carry os; this brings no-new-array into conformance.

_tools/eslint/rules/tsdoc-declarations-doctest

Added the missing top-level os field to _tools/eslint/rules/tsdoc-declarations-doctest's package.json, populated with the full operating-system enum from _tools/package-json/schema and positioned between engines and keywords per the canonical key ordering in _tools/package-json/standardize/lib/keys.json. 121 of 125 sibling packages under _tools/eslint/rules (96.8%) already carry this field; this closes the gap. The package's __stdlib__.envs.node marker documents that the rule depends on Node's vm and process builtins — it does not narrow platform support, and other packages carrying the same marker still declare the full os array.

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.

Validation

Checked:

• Structural extraction over all 125 members: file trees, package.json / manifest.json key sets, README heading sequences, and test/benchmark/example filenames.
• Semantic extraction per package covering exported-value kind, argument-validation prologue, error-message construction, require() dependency set, and JSDoc shape.
• Drift validation by three independent reviewers over every candidate correction, covering whether a deviation is intentional, whether tests or examples depend on it, and whether the majority pattern is the thing that should actually be applied.
• Ecosystem-wide presence before treating any absence as drift, measured across all 6225 @stdlib package.json files rather than within the namespace alone.
• Post-change verification: each modified file re-parsed; the added array is byte-identical to the value in the other 6127 occurrences and is exactly the schema's operating-system enum; resulting key order validated as a subsequence of _tools/package-json/standardize/lib/keys.json; diff confirmed additive with no reformatting of surrounding lines.

Deliberately excluded:

• test/fixtures/unvalidated.js, absent from 6 of 125 packages (95.2% conformance). The 119 conforming packages pair the fixture with a test/test.js block that feeds it to the RuleTester as extra valid cases, and the fixture contents are rule-specific. Adding the file alone would leave a dead, never-loaded artifact, and authoring the fixture plus its test block is new test coverage rather than a drift correction.
• "bin": {}, absent from 3 of 125 packages (97.6% in-namespace conformance). Only 576 of 6225 package.json files project-wide (9.3%) carry a bin key at all, and it is never populated anywhere in this namespace. The in-namespace prevalence reflects scaffold history, not a convention worth propagating.
• __stdlib__ removal from tsdoc-declarations-doctest, the sole member carrying the key. The declaration is accurate and the field is schema-documented and read by tooling under _tools/pkgs/.
• engines.node, which is ">=0.11.15" in require-file-extensions against ">=0.10.0" in the other 124. Normalizing it would relax a declared compatibility constraint rather than supply absent metadata, so it is left for a maintainer.
• Two stray @private annotations and one non-conforming internal function name (create rather than main in require-spaces). Both are cosmetic source-level deviations outside the scope of a metadata change.
• Features without a clear majority, listed under "Namespace summary" above.

Notes

• A namespace-level README.md section in 116 of 125 packages carries the Do not manually edit this section, as it is automatically populated marker for ## See Also. No generator-owned section, repl.txt, or .d.ts file is touched by this pull request.
• No open pull request targets this namespace or proposes this fix, and no pull request merged in the preceding 14 days applies it.

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.".

This pull request was written primarily by Claude Code. The namespace was surveyed programmatically, candidate corrections were reviewed by separate model instances, and the package.json edits and this description were generated and then verified against the repository's own package.json schema and key-ordering data.

---

@stdlib-js/reviewers

🤖 Generated with Claude Code

https://claude.ai/code/session_01DEXwr8MryTfYu483qyCqr4

---

Generated by Claude Code