fix(spectator): resolve input aliases in props and setInput

[nicobytes]

Fixes #15.

Problem

props and setInput() both funnel into setProps(), which calls ComponentRef.setInput(key, value). Angular resolves inputs by their public name (the alias). But both public APIs are typed by the class property name:

• props?: InferInputSignals<C> — keys are keyof C
• setInput<K extends keyof C>(input: K, ...)

So the keys TypeScript advertises are exactly the keys that fail at runtime. This is wider than the issue title: neither API accepts the class property name.

Call	TypeScript	Runtime
setInput('userName', v) — alias	OK	works
setInput('name', v) — property name	OK (keyof C overload)	NG0303, silently ignored
props: { name: v } — property name	OK	NG0303, silently ignored
props: { userName: v } — alias	TS2353	works
props: { name: v } + input.required({ alias })	OK	throws NG0950

The silent rows are the dangerous ones — the test just renders empty, with no obvious cause.

Fix

1. Runtime — resolve the key before handing it to Angular

A new internals/resolve-input-name.ts builds a resolver from reflectComponentType(type).inputs ({ propName, templateName, isSignal }, which covers decorator inputs, input(), input.required() and model()), and setProps() maps every key through it:

• a public name match wins, so existing behaviour is preserved exactly;
• otherwise fall back to propName → templateName;
• an unknown key is passed through untouched, so Angular still reports it (NG0303).

Public-name precedence is required, not cosmetic. A key can be the templateName of one input and the propName of another:

class C {
  @Input({ alias: 'age' }) numOfYears = 0;  // templateName 'age'
  @Input({ alias: 'collided' }) age = '';   // propName  'age'
}

props: { age: 1 } sets numOfYears today, and still does. There is a test pinning it.

setHostProps() is deliberately not touched — it assigns onto the host component instance, where the class property name is already correct. So createHostFactory / createDirectiveFactory / createPipeFactory are unaffected.

2. Types — let alias keys through without loosening what matters

Aliases cannot be derived from the type system: neither @Input('userName') nor input.required({ alias: 'userName' }) encodes the literal in the type. An index signature is the only way in. I type-checked the candidates with tsc --strict rather than guessing:

Candidate	alias keys	value types on known inputs	pre-declared props object
InferInputSignals<C> (status quo)	❌ TS2353	✅ enforced	✅ assignable
… | Record<string, unknown>	✅	❌ lost	✅
… & Record<string, unknown>	✅	✅	❌ breaks interface/class-typed
T | (T & Record<string, unknown>)	✅	✅	✅

The plain union lets props: { name: 123 } compile clean on a string input. The plain intersection is a breaking change for a common pattern, since interfaces get no implicit index signature:

interface MyProps { name: string }
const p: MyProps = { name: 'John' };
createComponent({ props: p });
// TS2322: Index signature for type 'string' is missing in type 'MyProps'

So this PR ships the last row:

export type InferInputProps<C> = InferInputSignals<C> | (InferInputSignals<C> & Record<string, unknown>);

Verified against the real Angular types: alias keys accepted; interface, type-alias and inferred-const sources still assignable; and { name: 999 }, { sigReq: 'nope' }, { sigOpt: input(5) }, { mdl: 42 } all still rejected.

Accepted trade-off, stated plainly: an unknown key in a props object literal is no longer a compile error. That is unavoidable — TypeScript cannot tell an alias from a typo. Runtime NG0303 remains the guard, which is exactly why the resolver passes unknown keys through instead of swallowing them.

The runtime fix and the type change are separate commits so the type trade-off can be reviewed, or rejected, without losing the runtime fix. The runtime fix alone already closes the issue's core complaint, since it makes the property name — what the type already advertises — actually work.

Result

@Component({ /* … */ })
class UserComponent {
  @Input('userName') name = '';
  age = input.required<number>({ alias: 'userAge' });
}

// before: NG0303 (silent) / NG0950 (throw) -> had to createComponent() then setInput()
// after: both spellings work
createComponent({ props: { name: 'John', age: 30 } });        // class property names
createComponent({ props: { userName: 'John', userAge: 30 } }); // public aliases

Known limitation

When a key is the public name of one input and a property of another, the type
describes the property while the resolver resolves the public name. So a collision
is only expressible in props when the two inputs agree on their value type:

class C {
  @Input({ alias: 'age' }) numOfYears = 0;   // public name 'age', number
  @Input({ alias: 'collided' }) age = '';    // property   'age', string
}

createComponent({ props: { age: 1 } });
// TS2322: type 'number' is not assignable to type 'string'
// — the type sees the `age` property; the runtime sets `numOfYears`

The runtime side is unchanged from today and there is a test pinning it. Nothing to
do about the type: it cannot describe two inputs sharing one name. Worth knowing,
not worth blocking on — Karma surfaced it while type-checking the specs.

Verification

yarn test (Karma)	341/341 — this one type-checks the specs, so it also validates the type change under real compilation
yarn test:jest	47 suites, 257 tests
yarn test:vitest	47 files, 227 tests
yarn build && yarn test:types	clean for all three entry points
yarn lint	0 errors; the 3 warnings are pre-existing on main (verified by comparison)

Tests

New props-alias-names.spec.ts, triplicated across the three suites (identical but for the import specifier), mirroring the layout of the existing set-input-alias-names.spec.ts. 15 cases:

• props + property name for @Input('x'), @Input({alias}), input.required({alias}), input(d, {alias}), model({alias})
• props + alias names (regression guard)
• props mixing both spellings in one object
• setInput() + property name on an aliased input
• createRoutingFactory({ props }), both spellings
• inputs with no alias, unaffected
• an unknown key is not redirected onto another input
• the public-name/property-name collision above

At the tests-first commit 8 fail with NG0303 / NG0950 and 7 pass as regression guards, so the RED phase is visible in the history.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes Spectator’s props and setInput() behavior for Angular inputs that use public-name aliases (including decorator inputs, signal input()/input.required(), and model()), by resolving provided keys to the public input name that ComponentRef.setInput() expects. It also widens the props typing to accept alias keys while preserving strong typing for known inputs, and adds tests + docs to lock in the behavior.

Changes:

• Add a runtime resolver that maps class property names to Angular’s public input names before calling ComponentRef.setInput().
• Update props typing to allow alias keys without losing value-type checking for known inputs.
• Add cross-runner tests (jasmine/jest/vitest), type tests, and documentation updates covering the new behavior.

Reviewed changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
type-tests/vitest/consumer.ts	Adds type-level coverage demonstrating props accepts both property names and alias keys while keeping known input value types checked.
type-tests/jest/consumer.ts	Same type-level coverage for the Jest entry point.
type-tests/jasmine/consumer.ts	Same type-level coverage for the Jasmine/default entry point.
projects/spectator/vitest/test/props-alias-names.spec.ts	Adds Vitest runtime tests for props/setInput() with aliased inputs, collisions, and unknown keys.
projects/spectator/jest/test/props-alias-names.spec.ts	Adds Jest runtime tests mirroring the Vitest suite.
projects/spectator/test/props-alias-names.spec.ts	Adds Jasmine/Karma runtime tests mirroring the Vitest suite.
projects/spectator/src/lib/types.ts	Introduces InferInputProps<C> to widen accepted props keys (including aliases).
projects/spectator/src/lib/spectator/create-factory.ts	Switches props typing in createComponentFactory pipeline to InferInputProps.
projects/spectator/src/lib/spectator-routing/create-factory.ts	Switches routing factory props typing to InferInputProps.
projects/spectator/src/lib/internals/resolve-input-name.ts	New internal helper building an input-name resolver via reflectComponentType(...).inputs.
projects/spectator/src/lib/internals/query.ts	Uses the resolver inside setProps() to normalize keys before delegating to Angular.
docs/src/content/docs/testing-components.md	Documents that props and setInput() accept both property names and public input names (aliases), and clarifies compile-time vs runtime validation.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[nicobytes]

@dominicbachmann 🙏