Summary
no-core-setoutput-non-string flags positive numeric literals (core.setOutput("count", 42)) but silently accepts negated/unary numeric literals such as -1 and +5. These carry the exact same implicit-coercion hazard the rule targets, so the omission is an inconsistency rather than an intentional scope boundary.
Evidence
nonStringKind() only inspects bare Literal nodes (no-core-setoutput-non-string.ts:17-22). -1 parses as a UnaryExpression (operator -, argument Literal 1), so nonStringKind returns null and the call is not flagged.
The rule's own test suite codifies this false negative as intended behavior:
// no-core-setoutput-non-string.test.ts:29 (inside the "valid" block)
`core.setOutput("count", -1);`So core.setOutput("count", 42) is an error but core.setOutput("count", -1) is accepted — both coerce identically ("42", "-1").
Proposed refinement
In nonStringKind, unwrap a UnaryExpression whose operator is - or + (and, optionally, ~) over a numeric Literal argument and report it as a numeric literal. Keep the existing low-false-positive philosophy — only unwrap when the operand is a literal number, not an arbitrary expression.
Acceptance criteria
Filed by ESLint Refiner (2026-07-01). First review of the no-core-setoutput-non-string rule; not a duplicate of open issues 42188-42190 / 42015-42017 / 41962-41963.
Generated by 🤖 ESLint Refiner · 216.1 AIC · ⌖ 12.1 AIC · ⊞ 4.7K · ◷
Summary
no-core-setoutput-non-stringflags positive numeric literals (core.setOutput("count", 42)) but silently accepts negated/unary numeric literals such as-1and+5. These carry the exact same implicit-coercion hazard the rule targets, so the omission is an inconsistency rather than an intentional scope boundary.Evidence
nonStringKind()only inspects bareLiteralnodes (no-core-setoutput-non-string.ts:17-22).-1parses as aUnaryExpression(operator-, argumentLiteral 1), sononStringKindreturnsnulland the call is not flagged.The rule's own test suite codifies this false negative as intended behavior:
So
core.setOutput("count", 42)is an error butcore.setOutput("count", -1)is accepted — both coerce identically ("42","-1").Proposed refinement
In
nonStringKind, unwrap aUnaryExpressionwhose operator is-or+(and, optionally,~) over a numericLiteralargument and report it as anumeric literal. Keep the existing low-false-positive philosophy — only unwrap when the operand is a literal number, not an arbitrary expression.Acceptance criteria
core.setOutput("count", -1)andcore.setOutput("count", +5)are flagged asnumeric literal.core.setOutput("count", String(-1)).-1case is moved from thevalidblock to aninvalidblock inno-core-setoutput-non-string.test.tswith the expected suggestion output.-someVar) remain unflagged to preserve the low-FP contract.Filed by ESLint Refiner (2026-07-01). First review of the
no-core-setoutput-non-stringrule; not a duplicate of open issues 42188-42190 / 42015-42017 / 41962-41963.