Consider re-enabling `no-empty-object-type` rule

[Maxim-Mazurok]

"@typescript-eslint/no-empty-object-type": [
  "error",
  {
    "allowInterfaces": "always", // to allow `interface DismissApprovalRequestMessage {}` in AccessApproval-v1, etc.
    "allowObjectTypes": "always" // to allow `deleteAccessApprovalSettings(request?: {...}): Request<{}>` in AccessApproval-v1, etc.
  }
],

was added because of

   143:15  error  An empty interface declaration allows any non-nullish value, including literals like `0` and `""`.
- If that's what you want, disable this lint rule with an inline comment or configure the 'allowInterfaces' rule option.
- If you want a type meaning "any object", you probably want `object` instead.
- If you want a type meaning "any value", you probably want `unknown` instead   @typescript-eslint/no-empty-object-type

and

   429:19  error  The `{}` ("empty object") type allows any non-nullish value, including literals like `0` and `""`.
- If that's what you want, disable this lint rule with an inline comment or configure the 'allowObjectTypes' rule option.
- If you want a type meaning "any object", you probably want `object` instead.
- If you want a type meaning "any value", you probably want `unknown` instead  @typescript-eslint/no-empty-object-type

Perhaps we should be more strict? Will need to examine generated types and actual implementation more closely, maybe it being a bit more lax is a good thing, not sure.

[Maxim-Mazurok]

Ⓜ Investigation findings:

• The current types branch contains 2,701 empty interfaces across 398 packages and 2,700 Request<{}> return types across 345 packages. Enabling the rule without changing generation would therefore break most of the generated catalog, not just a few edge cases.
• These are real Discovery shapes. For example, Access Approval defines DismissApprovalRequestMessage as an object with properties: {}, and delete operations return an empty Empty schema.
• The current declarations are looser than they look: TypeScript's {} accepts every non-nullish value, including numbers and strings. The rule is correctly identifying a type-safety gap.
• Record<string, never> models the intended empty JSON object more closely. A type-check probe confirmed both type Empty = Record<string, never> and interface Empty extends Record<string, never> {} accept {} while rejecting primitives and objects with populated string keys.

I recommend a staged generator change rather than only editing the ESLint template:

1. Emit named empty schemas as interface Name extends Record<string, never> {}.
2. Emit empty method responses as Request<Record<string, never>>.
3. Set allowInterfaces to with-single-extends and allowObjectTypes to never.
4. Add focused generation/type-level tests, then run the full all-services generation and lint path to identify any API-specific exceptions.

This would intentionally tighten public generated declarations and may affect consumers that currently assign primitives, populated objects, or declaration-merge fields into empty message interfaces, so it should be treated as a compatibility-sensitive change rather than an automatic lint cleanup.

Max Mini needs Big Max's explicit approval on direction before implementation starts.

[Maxim-Mazurok]

Big Max: the solution is understandable, the problem is that I'm not certain if this direction is actually good. I anticipate a number of interfaces that are declared as empty in the schema, but in reality the APIs would accept (or even expect) to receive some arguments. A more thorough investigation of actual API endpoints is required, at least a few spot-checks, where we identify empty interfaces that sound like are likely to accept parameters, and instead of relying on schema we should check documentation of related service for that endpoint.

For example, DismissApprovalRequestMessage described here and here is also mentioned here and defined to accept "Name": Name of the ApprovalRequest to dismiss. I'm not 100% sure that would be accepted by gapi, but it still creates a doubt, we shouldn't just limit people without having a very good reason for it.

[Maxim-Mazurok]

Ⓜ Follow-up endpoint-level investigation after Big Max's concern:

Catalog scan

• The current types branch still has 2,701 empty interfaces and 2,700 Request<{}> returns.
• I fetched the preferred Discovery document for 305 of 309 listed APIs (the four failures were retired/transient endpoints: Area120 Tables, Integrations, Data Labeling, and Poly).
• 413 methods reference an empty request schema, representing 372 distinct service/version/schema combinations.
• 405 of those methods expose at least one method parameter; all 427 such parameters are REST path parameters. Only eight methods have neither body fields nor method-specific parameters.

Official REST spot checks

• Access Approval dismiss: name is a path parameter and the body must be empty.
• Dataplex generateDataQualityRules: name is a path parameter and the body must be empty.
• Contact Center Insights publish: name is a path parameter and the body must be empty.
• Cloud Build accessReadWriteToken: repository is a path parameter and the body must be empty.
• GKE completeUpgrade: name is a path parameter and the body must be empty.

I also used Android Publisher migratePrices as a control: its REST body has fields, and the current Discovery document and generated MigrateBasePlanPricesRequest retain those fields rather than treating the request as empty.

The DismissApprovalRequestMessage discrepancy is therefore a gRPC-transcoding distinction rather than a missing gapi argument. Language-specific protobuf clients model name on the RPC request message; the REST endpoint moves name into the URL. Our generated dismiss signatures already require request.name, while DismissApprovalRequestMessage represents only the empty HTTP body.

Revised recommendation

The evidence supports a strict empty type for verified REST-empty request bodies, but not a blanket Record<string, never> rewrite of all 2,701 empty declarations. Those declarations also include responses and schemas used outside method bodies, which this pass has not classified endpoint by endpoint.

I recommend a narrower implementation:

1. Classify empty schemas by use: request body, response, and other schema references.
2. Emit Record<string, never> only for categories whose REST contract is explicitly empty (including protobuf Empty and verified empty request bodies).
3. Use a permissive object-only fallback such as Record<string, unknown> for unclassified empty schemas so primitives are rejected without blocking undocumented or future fields.
4. Keep the full-catalog generation/lint run as the compatibility check.

I have not changed generation yet; this narrower direction still needs Big Max's approval.

[Maxim-Mazurok]

Big Max: ok, create a draft PR, it's probably ok to "block" devs using types, as long as these are exceptions that they can work around in TS, and add value by flagging stuff they expect to work but that potentially doesn't. If it becomes too noisy in the future - hopefully we'll get feedback/issue from users...