Typescript's type mismatch does not result in a compile time error

Question

Typescript's type mismatch does not result in a compile time error

Within my code, I have a function with the following definition:

export async function removeUser(deleteUserId: Types.ObjectId)

There was an instance where I mistakenly called this function and passed a Mongoose object's id parameter, which is a string. This led to a runtime exception later in the code when I attempted to utilize the .equals() method that is present on an ObjectId but not on a string:

await removeUser(deleteUser.id);

Upon correcting this mistake by passing the ObjectId instead, everything functioned correctly:

await removeUser(deleteUser._id);

I am curious as to why TypeScript did not provide a compile time error when the argument was specified as an ObjectId but a string was being passed instead?

Edit: I have observed that the .id is declared as any, not specifically a string. Could this be a factor influencing the issue?

typescript mongodb mongoose

Answer 1

Answer №1

According to my observation, the .id is specified as any type, rather than a string type.

When using values of type any, you can assign them to any type without restriction.

const n: number = 'string' as any // This operation will not raise an error

The use of any serves as a way to bypass the type system. It's important to note that any is not type-safe and should be used sparingly.

For more information, refer to the official documentation:

Essentially, when using any, the compiler treats it as a way to disable type checking for that specific variable. It can be compared to adding an @ts-ignore comment before every usage of the variable.

Answer 2

According to my observation, the .id is specified as any type, rather than a string type.

When using values of type any, you can assign them to any type without restriction.

const n: number = 'string' as any // This operation will not raise an error

The use of any serves as a way to bypass the type system. It's important to note that any is not type-safe and should be used sparingly.

For more information, refer to the official documentation:

Essentially, when using any, the compiler treats it as a way to disable type checking for that specific variable. It can be compared to adding an @ts-ignore comment before every usage of the variable.

Answer 3

Answer №2

Absolutely, by implementing a method to validate for any type, we can ensure that values labeled as type any are not allowed:

type IfAny<T, Y, N> = 0 extends (1 & T) ? Y : N;

export async function excludeUser<Id extends Types.ObjectId>(removedUserId: IfAny<Id, never, Id>) {

If we provide any as an argument, the type of removedUserId will become never:

await excludeUser(removedUser.id);  // error, cannot assign type 'any' to type 'never'
await excludeUser(removedUser._id); // good to go

Experimentation Area

Answer 4

Absolutely, by implementing a method to validate for any type, we can ensure that values labeled as type any are not allowed:

type IfAny<T, Y, N> = 0 extends (1 & T) ? Y : N;

export async function excludeUser<Id extends Types.ObjectId>(removedUserId: IfAny<Id, never, Id>) {

If we provide any as an argument, the type of removedUserId will become never:

await excludeUser(removedUser.id);  // error, cannot assign type 'any' to type 'never'
await excludeUser(removedUser._id); // good to go

Experimentation Area

Answer 5

Answer №3

In the realm of Typescript, types only exist during compilation and are not present during runtime. This means that the Typescript type system is not foolproof; it cannot guarantee that a program will be error-free at runtime just because it compiles.

Regarding your query, when a variable is declared as any, you have free reign over it without any restrictions from Typescript. However, it is highly advised to use the any type with great caution.

For instance, if you define a variable obj as type any:

You can assign obj to any other variable (excluding those of type never)
You can access any properties on obj like obj.a.b.c.d
You can pass it to functions expecting parameters of different types, such as string

Check out this code example for a demonstration:

function onlyAcceptingNumber(a: number) {}

export async function doSomething(obj: any){
  // I can perform operations like:
  const a = obj.a * obj.b;
  // I can also access nested properties:
  console.log(obj.a.b.c.d);
  // and even call a function restricted to numbers with obj
  onlyAcceptingNumber(obj);
}

// however, there may be issues at runtime:
doSomething("123");
doSomething({ name: "John" });

In the provided scenario, although the doSomething function and both calls to it compile successfully, errors may arise during runtime.

To mitigate these risks, consider implementing measures like ESLint's no-explicit-any rule and resort to using any sparingly and as a final resort.

Answer 6

In the realm of Typescript, types only exist during compilation and are not present during runtime. This means that the Typescript type system is not foolproof; it cannot guarantee that a program will be error-free at runtime just because it compiles.

Regarding your query, when a variable is declared as any, you have free reign over it without any restrictions from Typescript. However, it is highly advised to use the any type with great caution.

For instance, if you define a variable obj as type any:

You can assign obj to any other variable (excluding those of type never)
You can access any properties on obj like obj.a.b.c.d
You can pass it to functions expecting parameters of different types, such as string

Check out this code example for a demonstration:

function onlyAcceptingNumber(a: number) {}

export async function doSomething(obj: any){
  // I can perform operations like:
  const a = obj.a * obj.b;
  // I can also access nested properties:
  console.log(obj.a.b.c.d);
  // and even call a function restricted to numbers with obj
  onlyAcceptingNumber(obj);
}

// however, there may be issues at runtime:
doSomething("123");
doSomething({ name: "John" });

In the provided scenario, although the doSomething function and both calls to it compile successfully, errors may arise during runtime.

To mitigate these risks, consider implementing measures like ESLint's no-explicit-any rule and resort to using any sparingly and as a final resort.

Typescript's type mismatch does not result in a compile time error

Answer №1

Answer №2

Answer №3

Similar questions

Utilizing Apollo plugin to retrieve arguments in a GraphQL resolver

Creating a bespoke numeric input component using React Native

Indicate the type of content returned by a Controller

What steps should I take to resolve an unhandled promise error in a React TypeScript application while making an axios POST request?

maximum number of records allowed in a nested document in MongoDB

Tips for resolving the AWS CDK setContext error while updating beyond v1.9.0

You cannot call this expression. The type '{}' does not have any callable signatures. Error TS2349

Formatting dates in MongoDB using moment.js

Error: Attempting to access the 'tokenType' property of an undefined object is not allowed

Is there a way to transfer information from Postgresql to mongoDB using Java programming?

When a selection is made in React MUI Virtualized Autocomplete, the autocomplete menu scrolls back to the top

Has the delete function API stopped working, failing to remove any items from the array as expected?

Importing CSS properties from MUI v5 - A comprehensive guide

Resolving a persistent AngularJS 1 constant problem with Typescript

What is the best way to ensure that the operations are not completed until they finish their work using RX

Mongo does not support restoring user passwords

Is there a way to trigger an image flash by hovering over a button using the mouseover feature in AngularJS2?

Using TypeScript and controllerAs with $rootScope

API endpoint generating a Vue component as a rendered output

"TypeORM's createConnection function on MacOS with PG database returns a Pending status even when using