[Planeshifter]

Description

What is the purpose of this pull request?

This pull request:

• brings plot/components/svg/clip-path and plot/components/svg/marks in line with their siblings in plot/components/svg. Both now build re-emitted render arguments with @stdlib/array/zeros, and the wrong autoRender default in the clip-path constructor JSDoc is fixed.

Namespace summary

• Members: 12 packages (rects has no package.json and is excluded).
• Features analyzed: file tree, package.json key sets, README sections, test/benchmark/example naming, public signature, return kind, validation prologue, error construction, JSDoc shape, and source dependencies.
• Features with a clear majority (≥75%, i.e., ≥9/12): package.json key sets (12/12), directories keys example/lib (12/12), error construction via format (10/10 packages that throw), the options plain-object check (10/10 packages that take options), the @stdlib/array/zeros dependency (10/12), the defaults.json/autoRender property files (10/12), and the documented autoRender=false default (9/10).
• Features without a clear majority (excluded): required vs. optional options (7/12), validate.js and events/ (7/12 each), and README, test/ and benchmark/ (3/12 each).

plot/components/svg/clip-path

onRender built its re-emitted arguments with [ 'render' ] plus push. It now preallocates with zeros( arguments.length+1, 'generic' ), like 10 of 12 siblings (83%). The constructor JSDoc gave the autoRender default as true, which contradicts lib/defaults.json, the property's own @default false, and 9 of 10 siblings that document the option (90%). It now says false.

plot/components/svg/marks

onRender built its re-emitted arguments with an empty array and repeated push calls. It now uses the same zeros( arguments.length+1, 'generic' ) preallocation as 10 of 12 siblings (83%). The arguments passed to emit are the same as before.

Related Issues

Does this pull request have any related issues?

None.

Reference Packages

Did the content of this pull request follow one or more existing packages? Answering is optional.

This pull request followed these packages:

• plot/components/svg/graph
• plot/components/svg/title

What carried over from the reference(s)?

• The onRender argument construction and the require placement of @stdlib/array/zeros.

What differed, or what did you have to work out yourself?

• Nothing.

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

• Structural features were extracted from the filesystem for all 12 packages.
• Semantic features were extracted from lib/main.js, lib/index.js and lib/validate.js, one agent per package.
• Three independent reviews checked each candidate: semantic intent, cross-references (tests, examples, and consumers in plot/ctor/plot/hist), and structural applicability. All three marked both corrections as confirmed drift.
• A local check confirmed that both packages still re-emit render with the same arguments (_render('a', 2) → render('a', 2)).
• Neither package has tests or a README, so no test expectations or documented contracts change.

Deliberately excluded

• annotations and defs lack defaults.json and the autoRender property. This is intentional: they are zero-argument components with no configurable state.
• symbols documents options as required although the code treats it as optional. The public-signature feature has no majority, so this is left for a separate change.
• rug declares two @throws {TypeError} tags, unlike its siblings. This is not material on its own.

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 PR was written primarily by Claude Code, as part of an automated cross-package drift analysis using a majority vote.

---

@stdlib-js/reviewers

---

Generated by Claude Code

[stdlib-bot]

Coverage Report

No coverage information available.

[Planeshifter]

Lint Changed Files fails with 53:1 error Invalid JSDoc tag (preference). Replace "constructor" JSDoc tag with "class" jsdoc/check-tag-names in clip-path/lib/main.js. The cause is on develop, not in this PR. The flagged line is unchanged here, and all 169 lib/main.js files in the repo that use * @constructor (none use @class) would fail the same way once touched.

The regression comes from 1dd0231 (build: delete legacy ESLint config ..., #10974). The legacy etc/eslint/.eslintrc.js set settings.jsdoc.tagNamePreference = { 'class': 'constructor' }, and the new flat eslint.config.js does not carry settings over. As a result, jsdoc/check-tag-names falls back to the plugin default, which prefers @class.

No fix PR exists yet. Proposed patch for the base JavaScript block in eslint.config.js, which belongs in a separate PR rather than this one:

 		'plugins': {
 			'n': pluginN,
 			'jsdoc': pluginJsdoc,
 			'@cspell': pluginCspell,
 			'stdlib': stdlibPlugin
 		},
+		'settings': {
+			'jsdoc': {
+				'contexts': [
+					'ArrowFunctionExpression',
+					'ClassDeclaration',
+					'ClassExpression',
+					'FunctionDeclaration',
+					'FunctionExpression'
+				],
+				'tagNamePreference': {
+					'class': 'constructor'
+				}
+			}
+		},
 		'rules': rules

The same settings probably belong in the TypeScript block too. A re-run would fail identically because the failure is deterministic, so I have not re-run the job. The TODO: uuid warning in the same file predates this PR and is non-blocking.

---

Generated by Claude Code