[TypeScript] typegen creating output which conflicts with @typescript-eslint/ban-types

[simonflk]

Description

Typegen output is offending @typescript-eslint/ban-types whose mission statement is

Some builtin types have aliases, some types are considered dangerous or harmful. It's often a good idea to ban certain types to help with consistency and safety.

-- README

Expected Result

Typegen output should not use incorrect types which are flagged by the @typescript-eslint/ban-types rule

Actual Result

The specific error is:

Don't use `{}` as a type. `{}` actually means "any non-nullish value".
- If you want a type meaning "any object", you probably want `Record<string, unknown>` instead.
- If you want a type meaning "any value", you probably want `unknown` instead.
- If you want a type meaning "empty object", you probably want `Record<string, never>` instead.e

And can occur on invokeSrcNameMap, eventsCausingServices, eventsCausingGuards, and eventsCausingDelays:

Reproduction

Typegen doesn't run on codesandbox, but the following machine will trigger the above error on [email protected]:

import { createModel } from 'xstate/lib/model';

export const testModel = createModel(
  {
    name: null as null | string,
  },
  {
    events: {
      setName: (name: string) => ({
        name,
      }),
      reset: () => ({}),
    },
  },
);

export const surveyFormMachine = testModel.createMachine({
  tsTypes: {},
  id: 'test',
  initial: 'idle',
  context: testModel.initialContext,
  states: {
    idle: {},
  },
  on: {
    reset: {
      actions: 'resetContext',
    },
    setName: {
      actions: 'setName',
    },
  },
});

Additional context

XState 4.29.0 statelyai.stately-vscode 1.5.6

[simonflk]

I'm currently working around this with an override in my eslint.json to disable that rule for *.typegen.ts

[Andarist]

@mattpocock we can probably just output never at those locations instead of {} - but it's best to double-check that and add those to all existing type gen tests in this repo. Maybe we could even just skip those keys if they are empty~? That could be even better as we'd save some parsing time.

[mattpocock]

Yes, although applying any linting whatsoever to generated files is probably not a great idea. When we release the CLI, we'll even be able to gitignore these assets and generate them on CI.

This is a cheap enough change to make, though.

[horacioh]

When we release the CLI, we'll even be able to gitignore these assets and generate them on CI.

@mattpocock Is there any example on how to do this on GH Actions? thanks in advance!

[mattpocock]

@horacioh Yes, see the CLI docs:

https://xstate.js.org/docs/packages/xstate-cli/#xstate-cli

[horacioh]

YES!! I saw it and forgot to mention it here ;)