Record types are not enforced strictly enough when passed as parameters

[NVP12345]

🔎 Search Terms

record type enforcement strict parameters

🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about Record, Exclude, etc.

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAHjAvDAFABwIYCcMFsBcMASgKahYAmAPGAK64BGJWANDHY8wHwCUSXMAN4BfANwAocQHopMAGIYAlgBsIbDBBgk4aMlBIVxcFIJhQAFooiEA5FZtswIKLYwOYWMiEq2A-DZhhHkkZGAAFDQgSTUUwck9gKGUAT3FQSFhkpCEzS2sYOwh3JxcCtzYE7wo-ALEjFGSeCSA

💻 Code

const recordFunction = (param: Record<number, number>) => {};

recordFunction({ this: 'is', not: 'a', record: '?' }); // Fails, as expected

const y = { this: 'is', not: 'a', record: '?' };
recordFunction(y); // Passes incorrectly

🙁 Actual behavior

No error is raised by TypeScript. This allows for almost any object to be passed to a function that expects a Record, which will miss finding developer errors and may result in significant inconsistencies at runtime.

🙂 Expected behavior

I expect an error be raised.

Additional information about the issue

No response

[RyanCavanaugh]

(auto-generated response)

FAQ Responses

(Indirect) Excess Properties Are OK

The issue being raised is about TypeScript allowing incorrect types to pass as Records due to excess property checks. The FAQ entry indirectly addresses this by explaining that in TypeScript, object types are not "sealed", which means they can have extra properties beyond what is specified. This is seen in your example: when using an object literal directly, excess properties are checked, and TypeScript flags an error as expected; however, once the object is assigned to a variable, any excess properties are allowed, leading to the behavior you observed.

The FAQ explains that object types in TypeScript aren’t closed, which results in the language permitting additional properties in assigned variables, even if they exceed the specified type. This is why recordFunction(y) does not raise an error although recordFunction({ this: 'is', not: 'a', record: '?' }) does. Therefore, while TypeScript's design permits broader object compatibility, it doesn't enforce strict record type checking when passing parameters via variables.

---

Similar Issues

Here are the most similar issues I found:

• (73%) #60289 - Typescript allows assigning anything to Record<number, ...> - The issue highlights a concern where TypeScript allows assignments to a Record<number, ...> which should be restricted. In the provided code, an object with a non-number typed key ('something') is assigned to a Record<number, string>, yet no error is thrown. This behavior leads to confusion as the expectation is that TypeScript should enforce type constraints strictly to prevent non-compliant key types from being assigned to records that expect only number keys.

• (72%) #44135 - Incorrect type check when passing record as "interface with optional field" argument - The issue describes a type-checking discrepancy in TypeScript when passing a record with a specific structure as an argument to a function expecting an interface with an optional field. Specifically, it highlights that passing an object like Record<string, number> to a function expecting a parameter of type interface A { x?: string; } does not trigger a TypeScript error, even though logically, the value associated with key 'x' is not a string. This behavior is contrasted with a similar setup where directly passing an object with { x: 1 } correctly raises a type error because a number is not assignable to a string or undefined, which is expected behavior.

• (72%) #42096 - Record<string, any> or object is not compatible with object like types when appears as an argument of an arrow function - The problem described centers on the expectation that Record<string, any> should match all object-like structures, particularly when used as a parameter type in arrow functions. However, the current TypeScript behavior does not align with this expectation, as arrow functions have stricter type checking rules compared to regular functions, making parameters with Record<string, any> and object types like { key: number } incompatible. This behavior highlights a common misconception about type compatibility in TypeScript, particularly in scenarios involving structural type systems and the nuances associated with object type inheritance and polymorphic behavior in functional parameters.

• (71%) #60543 - Type checking shows unexpected behavior when a function argument is defined with a partial object. - The issue involves how TypeScript handles type safety with partial objects used as function arguments, particularly when those objects are defined through index signatures or the Record utility type. The user demonstrates through multiple examples that a function expecting a partially defined object type does not provide an error when passed objects with similar properties but different type definitions, such as an object with numeric values instead of strings. This behavior persists even with strict type checking settings enabled, such as 'noImplicitReturns' and 'noUncheckedIndexedAccess'. The unexpected acceptance of these objects without error suggests a gap in TypeScript's type enforcement that the user has identified.

• (71%) #57272 - Template literal string types in Record not showing error - Issue Template literal string types in Record not showing error #57272 highlights a concern with TypeScript's type checking when using template literal string types as keys in a Record type. In the provided code, a function takes a parameter of type Record<foo_${string}, boolean>, implying all properties with keys starting with foo_ must be boolean. However, when an object obj is passed to this function, it includes a property bar that does not conform to the foo_${string} pattern, yet no error is thrown. This raises questions about whether the type system should enforce stricter checks on the conformity of keys in such cases, indicative of perceived unexpected behavior or misunderstanding of object property excessiveness handling in TypeScript.

If your issue is a duplicate of one of these, please close this issue. Otherwise, no action is needed. Thanks!