feat(directive): validate input transforms like ngtsc

[ashley-hunter]

Stack (2/5): #493 inputs/outputs → #494 transform validation → #495 queries: → #496 .d.ts transform types → #504 signal API import identity. This is #494.

Checks input transforms the way ngtsc does, for both @Input({ transform }) and inputs: [{ transform }].

The bug

ngtsc rejects a transform it can't prove is a usable function (parseDecoratorInputTransformFunction). oxc accepted anything, so code that fails to build with ngc compiled here, e.g.

const toNumber = (v: string) => Number(v);

@Directive({ selector: '[d]' })
export class D {
  @Input({ transform: toNumber }) value!: number;   // ngtsc: Input transform must be a function
}

The fix

Each rule matches ngtsc, with its diagnostic word for word and in its order (inputs: entries, then members):

• not a function: literals, classes, enums, calls, satisfies, uninitialized lets, static getters/setters/fields without a value, the Number/String globals and members like Math.round, and function expressions reached through a variable, property access or parentheses (only one written directly as the property value is analyzable)
• generic, or overloaded: more than one call signature. An overloaded function or static method is checked at its first declaration, not its implementation.
• first parameter: untyped, a spread, or typed with a same-file type that isn't exported. Like ngtsc's assertEmittableInputType, only type references by plain name are checked, so typeof X and X.Y pass. Type parameters (the class's, mapped, infer, generic signatures) are rejected, and so are interfaces and type aliases exported only through export { X }.
• name clash: a static ngAcceptInputType_<name> member already on the class. This is also checked for imported, namespaced and global (parseInt) transforms.

The evaluator learns functions to do this: same-file function declarations and static methods resolve to their definitions, and cond ? a : b or T?.f resolve to the function they pick. A transform reached through such a reference (T.f where const T = { f }) is emitted as the function's own name, as ngtsc does. The lib functions parseInt, isNaN, ... are accepted. Like ngtsc, a shorthand { transform } whose variable holds an arrow or function expression (also through a const object, a spread or destructuring) is checked and emitted as that function, while naming it (transform: t) is still rejected. A function passed to a helper that returns the transform (inputs: make('x', (v: string) => ...), @Input(opts(...))) is checked the same way, including the helper's type parameters.

@Input and the other member decorators are also recognised through a namespace import (@core.Input), like @core.Component already was, but only when the namespace is import * as core from '@angular/core'. The check reads the import as written, so a resolvedImports rewrite of the path doesn't hide it.

Deliberate differences and known gaps:

• Static method: for transform: Utils.coerce ngtsc emits the bare method name. That name isn't in scope, so it either throws or binds an unrelated same-named function; oxc keeps the written expression instead.
• Other files: an imported transform can't be inspected from one file and is assumed to be a function (only the name clash is checked). A namespace member (u.g) reports could not be referenced, where ngtsc reads the file and can report a more specific error (e.g. cannot be generic). Errors about a transform declared in another file (an import, or a lib global like Number) point at the expression, since ngtsc's target is in a file oxc doesn't read.
• declare global types aren't checked: oxc can't tell a new global from an augmented lib type.
• Aliased imports: import {Input as In} isn't recognised; member decorators are matched by name.

A function expression that reaches the transform through a spread or a rest parameter is rejected with ngtsc's "Input transform must be a function" / "could not be determined statically".

@Input(...) options that come from another module (@Input(OPTS), ns.OPTS, {...OPTS}, or an imported alias/required) report the "imported from another module" error on the argument. Before, the input compiled without its alias, required flag or transform, and no error was shown.

A global declared outside the file (the DOM's atob, a project's declare function) is assumed to be a function, like an imported transform: it's emitted as written and only the ngAcceptInputType_ clash is checked. ES2022 lib non-functions (including Intl and Reflect) keep ngtsc's errors, members of globals stay "could not be determined statically", and a shorthand { transform } naming a global is still rejected, as in ngtsc.

Tests

Added to the ngtsc snapshot: Angular's input transform specs from ngtsc_spec (non-function values, generic, overloaded, spread, untyped, non-exported type, ngAcceptInputType clash), plus probes of each rule, of the type checks above and of how ngtsc describes values in these errors. Skipped with a reason: the three ngtsc_spec cases and the u.g probe that need declarations from another file, the static method, the aliased @Input, declare global, and the cases that differ only in where the error points (their messages are checked in a separate test). Other separate tests cover the static-method case, an overloaded static method, and namespaced member decorators for @angular/core versus another module.