Dynamic Parameters using a single field named name avoids type safety

[turgid-tributary]

I'm not sure if Discussions is the right place to post this, but since I just started using xstate, here goes!

I was creating a dummy project for myself with no other dependencies than xstate 5.6.2 and typescript 5.3.3. I copy and pasted the following code snippet from the documentation at https://stately.ai/docs/typescript#dynamic-parameters

import { setup } from 'xstate';

const feedbackMachine = setup({
  types: {
    context: {} as {
      user: { name: string };
    }
  },
  actions: {
    greet: (_, params: { name: string }) => {
      console.log(`Hello, ${params.name}!`);
    }
  }
}).createMachine({
  context: {
    user: {
      name: 'David'
    }
  },
  // ...
  entry: {
    type: 'greet',
    params: ({ context }) => ({
      name: context.user.name
    })
  }
});

Oddly, when I modified this section of the code

...
    params: ({ context }) => ({
      name: 42 //  passing in a number instead of `context.user.name`, but the Typescript compiler does not complain
    })
...

The Typescript compiler does not complain about the fact that I'm using a number instead of a string. In fact, the accepted type of params appears to be any.

However, if I change the name of the parameter to anything BUT name, then type safety works as I would expect. For example:

...
  actions: {
    greet: (_, params: { notName: string }) => {
      console.log(`Hello, ${params.notName}!`);
    }
  }
}).createMachine({
...
  entry: {
    type: 'greet',
    params: ({ context }) => ({
      notName: 42 // ❌ now the compiler complains that I'm not using a string here
    })
...

My question is simply why this might be happening? It seems like it won't be a problem for me as long as none of my actions w/dynamic parameters use name as one of the parameters, but I'm still curious.

Note: I thought there might be some weird collision about a name field existing in the type of the context and the greet action's params, but that's not true. I changed all occurrences of name to notName in the whole snippet and the compiler correctly complained that I was trying to pass in 42 where a string should be.

Note: I also tried out an action with params: { name: string, foo: number } (ie an extra param other than name) and that failed compilation when given a number for name as I would expect.

[Andarist]

My question is simply why this might be happening? I

It's because TS is a structural type system and functions... have .name property that is a string. So to hit this problem you specifically have to have name: string in your params (where a name's type usually would be a string).

I had a PR fixing this (here) but we decided to close it since this is not a super common problem and it would require us to do "weird things" to overcome this. Maybe we should revisit that decision though

[turgid-tributary]

Ah, thank you for the explanation! Given the rarity of the problem (I certainly don't see myself having just name: string as the params for any of my use cases), I'm happy just knowing this case exists and avoiding it :)