Summary
prefer-core-logging suggests replacing every console.* call with a core.* method. But the two families write to different streams: console.error / console.warn go to the process stderr, while @actions/core logging methods (core.info / core.error / core.warning / core.debug) emit GitHub Actions workflow commands to stdout. For processes that own stdout as a data/protocol channel — the stdio MCP servers and transports in actions/setup/js — moving diagnostics onto stdout corrupts the JSON-RPC stream. The stream change (stderr -> stdout) is not behavior-preserving.
Grounded evidence (all linted; config ignores only *.test.cjs)
safe_outputs_mcp_server.cjs:101 — console.error(...) in the stdio server startup catch path (the server writes JSON-RPC to stdout).mcp_scripts_mcp_server.cjs:87 and :105 — console.error(...) usage/startup errors.mcp_http_transport.cjs:295 — console.error("MCP HTTP Transport error:", error).safe_outputs_mcp_server_http.cjs, mcp_scripts_mcp_server_http.cjs — same pattern.
These files deliberately log to stderr precisely to keep stdout clean for the protocol. Rewriting to core.error would write ::error::... to stdout and break framing.
Acceptance criteria
- Do not offer a
core.* rewrite for console.error / console.warn (stderr -> stdout is a semantic change), or exclude MCP server/transport entrypoints from the rule (config ignores glob, or a documented filename/heuristic guard).
- At minimum, downgrade
console.error / console.warn to report-only (no autofix) so the harmful transform is never auto-applied.
- Add tests:
console.error / console.warn produce no autofix (or no report) in the excluded contexts; console.log / console.info -> core.info still behaves as today.
- Document the stream-semantics rationale in the rule's README section so future readers understand why stderr logging is intentionally exempt.
Generated by 🤖 ESLint Refiner · 312.3 AIC · ⌖ 12.9 AIC · ⊞ 4.6K · ◷
Summary
prefer-core-loggingsuggests replacing everyconsole.*call with acore.*method. But the two families write to different streams:console.error/console.warngo to the process stderr, while@actions/corelogging methods (core.info/core.error/core.warning/core.debug) emit GitHub Actions workflow commands to stdout. For processes that own stdout as a data/protocol channel — the stdio MCP servers and transports inactions/setup/js— moving diagnostics onto stdout corrupts the JSON-RPC stream. The stream change (stderr -> stdout) is not behavior-preserving.Grounded evidence (all linted; config ignores only
*.test.cjs)safe_outputs_mcp_server.cjs:101—console.error(...)in the stdio server startup catch path (the server writes JSON-RPC to stdout).mcp_scripts_mcp_server.cjs:87and:105—console.error(...)usage/startup errors.mcp_http_transport.cjs:295—console.error("MCP HTTP Transport error:", error).safe_outputs_mcp_server_http.cjs,mcp_scripts_mcp_server_http.cjs— same pattern.These files deliberately log to stderr precisely to keep stdout clean for the protocol. Rewriting to
core.errorwould write::error::...to stdout and break framing.Acceptance criteria
core.*rewrite forconsole.error/console.warn(stderr -> stdout is a semantic change), or exclude MCP server/transport entrypoints from the rule (configignoresglob, or a documented filename/heuristic guard).console.error/console.warnto report-only (no autofix) so the harmful transform is never auto-applied.console.error/console.warnproduce no autofix (or no report) in the excluded contexts;console.log/console.info->core.infostill behaves as today.