Skip to main content

no-wrapper-object-types

Disallow using confusing built-in primitive class wrappers.

✅

Extending "plugin:@typescript-eslint/recommended" in an ESLint configuration enables this rule.

🔧

Some problems reported by this rule are automatically fixable by the --fix ESLint command line option.

The JavaScript language has a set of language types, but some of them correspond to two TypeScript types, which look similar: boolean/Boolean, number/Number, string/String, bigint/BigInt, symbol/Symbol, object/Object. The difference is that the lowercase variants are compiler intrinsics and specify the actual runtime types (that is, the return value when you use the typeof operator), while the uppercase variants are structural types defined in the library that can be satisfied by any user-defined object with the right properties, not just the real primitives. JavaScript also has a "wrapper" class object for each of those primitives, such as Boolean and Number. These wrapper objects are assignable to the uppercase types, but not to the lowercase types.

Using the primitives like 0 instead of object wrappers like new Number(0) is generally considered a JavaScript best practice. JavaScript programs typically work with the real number primitives, rather than objects that "look like" numbers. Primitives are simpler to conceptualize and work with == and === equality checks -- which their object equivalents do notDeepEqual. As a result, using the lowercase type names like number instead of the uppercase names like Number helps make your code behave more reliably.

Examples of code for this rule:

let myBigInt: BigInt;
let myBoolean: Boolean;
let myNumber: Number;
let myString: String;
let mySymbol: Symbol;

let myObject: Object = 'allowed by TypeScript';
Open in Playground
.eslintrc.cjs
module.exports = {
  "rules": {
    "@typescript-eslint/no-wrapper-object-types": "error"
  }
};

Try this rule in the playground ↗

Options​

This rule is not configurable.

When Not To Use It​

If your project is a rare one that intentionally deals with the class equivalents of primitives, it might not be worthwhile to use this rule. You might consider using ESLint disable comments for those specific situations instead of completely disabling this rule.

Further Reading​

Resources​