[TASK] Add reusable Node command workflow

[CybotTM]

Summary

Adds reusable-node-command.yml — a shared workflow for Node.js-based checks, mirroring the structure of reusable-php-command.yml (checkout → set up runtime → cached install → run command).

There is currently no Node/JS reusable in this repository, which is why JS test jobs in consumer repos stay inline — e.g. the theme-js-tests job in TYPO3-Documentation/render-guides#1196, which is meant to be swapped to this workflow once it is available.

Fit check (2026-07-04): an org-wide sweep (code search + per-repo workflow grep across all 41 non-archived repos) found exactly one Node/JS CI job in the org today — render-guides' theme-js-tests. The input surface below covers it zero-config beyond paths, and cache/cache-dependency-path keep the workflow usable for lockfile-less or yarn/pnpm consumers without speculative package-manager switches.

Inputs

Input	Default	Purpose
command	(required)	Command to run after install, e.g. npm test
working-directory	.	Directory containing package.json (monorepo support)
node-version-file	''	e.g. .nvmrc, relative to the repository root
node-version	''	Explicit version, alternative to node-version-file
install-command	npm ci --no-progress	Dependency install command
cache	auto	auto caches via npm only when the lock file exists (mirrors the graceful degradation of reusable-php-command.yml's composer cache); npm/yarn/pnpm force caching; '' disables
cache-dependency-path	''	Lock file for the cache key; falls back to the manager's lock file (package-lock.json, yarn.lock, pnpm-lock.yaml) in working-directory

Example consumer

jobs:
  theme-js-tests:
    uses: TYPO3-Documentation/.github/.github/workflows/reusable-node-command.yml@main
    with:
      working-directory: packages/typo3-docs-theme
      node-version-file: packages/typo3-docs-theme/.nvmrc
      command: npm test

Notes

• Caching needs no consumer action in either direction: with a lock file you get the npm cache, without one the cache is skipped instead of failing setup-node. Only an explicit cache: npm/yarn/pnpm fails loudly when the lock file is missing - which is then a real configuration error.
• actions/checkout and actions/setup-node are SHA-pinned at the current latest (v7.0.0 / v6.4.0, verified via API). The existing reusables still pin checkout v6.0.2 — deliberately not touched here; can be bumped in a follow-up.
• run: ${{ inputs.command }} is the same trust model as reusable-php-command.yml: workflow_call inputs come from the calling repository's committed workflow file, not from external users.
• Hardened to pass the CI gate proposed in [FEATURE] Add CI gate for the shared reusable workflows (lint, security, conformance, freshness) #16: persist-credentials: false on the checkout, justified zizmor: ignore[template-injection] annotations on the two command steps (code by contract — see the consumer contract note in [FEATURE] Add CI gate for the shared reusable workflows (lint, security, conformance, freshness) #16's README update), and the input descriptions state that command inputs must be static literals.
• Independent review round (code + security + runtime reviewers) applied: the cache resolver now derives the lock file name from the forced manager (yarn → yarn.lock, pnpm → pnpm-lock.yaml), fixing the case where forcing a non-npm cache silently looked for package-lock.json.
• Validated locally with actionlint 1.7.12, yamllint 1.38.0 and zizmor 1.26.1 (all rc=0), individually and in a simulated merged state with [FEATURE] Add CI gate for the shared reusable workflows (lint, security, conformance, freshness) #16.
• The README workflow table gains a reusable-node-command.yml row (status: Available), per the repo's documentation convention - detailed input/secret docs live in the YAML inputs: definitions.

[linawolf]

Thanks for the work here. I understand the goal of keeping CI patterns consistent, but at the moment I do not see enough benefit for a dedicated reusable Node workflow.

As far as I know, the only Node usage in the TYPO3 Documentation org is the render-guides theme asset/test job. That job is currently small and explicit: checkout, setup Node from .nvmrc, install with npm ci, and run npm test.

For a single consumer, a generic reusable workflow adds abstraction and maintenance surface without really removing duplication. The extra flexibility for cache modes, package managers, install commands, and generic command execution looks useful only if we expect more Node consumers.

My preference would be to keep the Node job inline in render-guides for now and revisit this once we have at least a second real consumer or repeated Node CI logic.

[CybotTM]

@linawolf I see your points, and I had similar thoughts. Let me explain why I still opened this PR:

IMO, consistency is often more valuable than avoiding a few extra lines of code. Maintenance burden also cannot be measured by lines of code alone.

Another reason for this move is to avoid spreading CI patterns and external action usage across multiple repositories. From a security and governance perspective, having one reviewed central place as the gatekeeper makes this easier to control and maintain.

But as I wrote: your points are valid, and I think mine are too. So I’m afraid the hard part is now yours: deciding which side weighs more. Sorry. ;-)