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
- Use `Record<string, never>` when you mean exactly the empty object
- Use `object` or `Record<string, unknown>` when you mean 'some object'
- Model the real members in an interface or type literal
- Allow intentional uses via the rule config (allowWithName regex or interface/object allowances)
- 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
- Forbid `{}` annotations in the house style guide and point at Record<string, never> and Record<string, unknown>
- Let the editor surface the rule live via the oxc language server so `{}` is fixed while typing
- Review generated .d.ts and refactored types for orphan `{}` leftovers
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
- 'The `Object` type actually means "any non-nullish value"
- encountered allocation error
- Prefer explicitly define the object shape
- Don't use `Function` as a type
- Do not use any type assertions.
AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20).
Data as JSON: /api/errors/35043aed2c73ddb6.
Report an issue: GitHub.