IMO this would be a hard no because checking for this requires type information.
The rule is intended to be a fast, syntax-only check for people misusing the {} type -- adding type info to the rule is a breaking change that limits who can use the rule -- so generally we don't do it unless there's a REALLY good reason.

There's potential scope for this in a new rule -- but also this seems like it would be a difficult thing to check.

What does it mean to "generate" a type?
What constructs would we be checking to see if the type is {}?
Realistically any type operation could result in {} and additionally any usage of a generic type could result in {} -- does that mean we should check every single intersection, conditional type, and generic type reference in the codebase? That seems very slow and heavy!

adding type info to the rule is a breaking change that limits who can use the rule

I see. I agree that it's not appropriate as an option of no-empty-type.

Still, it would be nice if there was some other way to prevent mistakes like the one above.
The example above is actually a simplified representation of the code I found while fixing a bug.
Specifically, if the {} type is used as a parameter to a function, it is similar to if the any type is used as a parameter type, which is less type-safe.

type Data = { name: string; num: number };
type NullableData = null | Data;

function foo(param: Omit<NullableData, 'name'>) { }

foo("aaa"); // no error
foo({}); // no error
foo(1); // no error

That seems very slow and heavy!

What if we only checked when type operations are used and when they are used as generic arguments?
For nested operations, I think we can optimize by only checking the type that is finally created.

type Computed = Omit<NullableData, 'name'>; // check

function foo (arg: Computed) { // Uncheck for the references
}

What if we only checked when type operations are used and when they are used as generic arguments

But how can we tell that Omit<NullableData, 'name'> under the hood uses an &?
We can't without type information!

This is the difficult problem to solve.

At its core you really want to just check every single intersection type across the codebase to look for {} -- which is conceptually simple enough.
However type aliases with generics mask an underlying & operation -- which means we can only assume that every single type reference with a generic might hide an & operation and thus we would need to check it.

Okay, so as an alternative, what do you think about adding a rule like no-unsafe-parameters which checks whether {} is used in function & generic parameters or not? This is because it allows almost any type if {} is used in the parameter type, it behaves almost like any.

playground

type Data = { name: string; num: number };
type NullableData = null | Data;

function wrongFunc(param: Omit<NullableData, 'name'> // Unexpected "{}"
) { }

wrongFunc("aaa");
wrongFunc(123);
wrongFunc({});

type WrongFunc< T extends  Omit<NullableData, 'name'> // Unexpected "{}"
> = T;

type A = WrongFunc<1>;
type B = WrongFunc<{}>;

// argument, it is easy to detect with ts error.
function foo(arg: number) {}
declare const arg: Omit<NullableData, 'name'> ;
foo(arg); // ts error 👍

This makes me nervous. I don't have hard data, but I suspect {} becomes the default inferred type parameter in more cases than we'd expect.

If someone could make a prototype version of the rule and run it on typescript-eslint & a few other large codebases, that would be helpful. I think we'll want to see real-world proof of whether this is helpful.

If someone could make a prototype version of the rule and run it on typescript-eslint & a few other large codebases, that would be helpful. I think we'll want to see real-world proof of whether this is helpful.

Sounds like a good idea. I'll look into it. Thanks

Hi, @JoshuaKGoldberg
I implemented a roughly implemented rule and tested it by setting it up in typescript-eslint, nest, strapi, and trcp projects.

I couldn't find any particular errors in trcp and strapi.
An error occurred in typescript-eslint, but it's not a concern since it was caused intentionally by using the {} type.
(It would probably be better to ignore the operand type when an actual rule is implemented. NonNullable<unknown>)

A meaningful error was found in the nest project. (here)

    //  {} type
    const keepaliveKeys: Record<
      keyof GrpcOptions['options']['keepalive'],
      string
    > = {

As shown in this PR, an incorrect type operation resulted in a {} type. (simplified example on typescript playground)