oxc-project/oxc · warning · OxcDiagnostic

Do not use the empty object type literal.

Error message

Do not use the empty object type literal.

What it means

The second message of oxlint's no-empty-object-type rule, reported for the empty object type literal {} used outside interface declarations (type aliases, annotations, generic arguments). The type {} means 'any non-nullish value': `let x: {} = 42` type-checks, which is almost never what the author intends, so the rule flags it per the shared help text at no_empty_object_type.rs:19.

Source

Thrown at crates/oxc_linter/src/rules/typescript/no_empty_object_type.rs:27

use oxc_macros::declare_oxc_lint;
use oxc_semantic::NodeId;
use oxc_span::Span;
use schemars::JsonSchema;
use serde::{Deserialize, Serialize};

use crate::{
    AstNode,
    context::LintContext,
    fixer::RuleFixer,
    rule::{DefaultRuleConfig, Rule},
    utils::deserialize_regex_option,
};

fn no_empty_object_type_diagnostic<S: Into<Cow<'static, str>>>(
    span: Span,
    message: S,
) -> OxcDiagnostic {
    OxcDiagnostic::warn(message)
        .with_help("To avoid confusion around the {} type allowing any non-nullish value, this rule bans usage of the {} type.")
        .with_label(span)
}

#[derive(Debug, Default, Clone)]
pub struct NoEmptyObjectType(Box<NoEmptyObjectTypeConfig>);

#[expect(clippy::struct_field_names)]
#[derive(Debug, Default, Clone, Deserialize, JsonSchema)]
#[serde(rename_all = "camelCase", default, deny_unknown_fields)]
pub struct NoEmptyObjectTypeConfig {
    /// Whether to allow empty interfaces.
    allow_interfaces: AllowInterfaces,
    /// Whether to allow empty object type literals.
    allow_object_types: AllowObjectTypes,
    /// A stringified regular expression to allow interfaces and object type aliases with the configured name.
    ///
    /// This can be useful if your existing code style includes a pattern of declaring empty types with `{}` instead of `object`.

View on GitHub (pinned to e1e7af627c)

Solutions

  1. Use `Record<string, never>` when you mean exactly the empty object
  2. Use `object` or `Record<string, unknown>` when you mean 'some object'
  3. Model the real members in an interface or type literal
  4. Allow intentional uses via the rule config (allowWithName regex or interface/object allowances)
  5. Inline disable comment for a one-off

Example fix

// before
function log(value: {}) {
  console.log(value);
}

// after
function log(value: Record<string, unknown>) {
  console.log(value);
}
Defensive patterns

Strategy: validation

Validate before calling

npx oxlint --deny-warnings .

Prevention

When it happens

Trigger: `let x: {} = f();`, `function log(v: {}) {}`, `type T = {};`, `Foo<{}>` - any object type annotation or alias with zero members that the rule's allowances do not cover.

Common situations: Developers coming from languages where {} reads as 'empty record'; refactors that strip members but leave the {} behind; strict lint presets enabling the restriction rule by default.

Related errors


AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/35043aed2c73ddb6. Report an issue: GitHub.