Important: This documentation covers Yarn 1 (Classic).
For Yarn 2+ docs and migration guide, see yarnpkg.com.

Package detail

eslint-plugin-return-types-object-literals

upload-io1.5kMIT1.0.1

Ensures explicit return types on functions and lambdas that return object literals.

readme

ESLint Rule: return-types-object-literals/require-return-types-for-object-literals

Requires return types on lambdas that return object literals.

Installation

npm install --save-dev eslint-plugin-return-types-object-literals

.eslintrc.yaml:

root: true
parser: "@typescript-eslint/parser"
parserOptions:
  project: "./tsconfig.json"
plugins:
  - "@typescript-eslint"
  - "return-types-object-literals" # ← Add this
rules:
  # ↓ And this:
  "return-types-object-literals/require-return-types-for-object-literals": error

Examples

const a = () => ({
  // Error: "Return type missing"
  propA: true,
  propB: true
});

const b = () => {
  // Error: "Return type missing"
  return {
    propA: true,
    propB: true
  };
};

const a2 = (): Foo => ({
  // OK
  propA: true,
  propB: true
});

const b2 = (): Foo => {
  // OK
  return {
    propA: true,
    propB: true
  };
};

const c = () => {
  // OK
  const result = {
    propA: true,
    propB: true
  };

  return result;
};

Benefits

Ensures excess property checking is performed on objects returned by lambdas.

type Foo = { a: boolean }

function foo(callback: () => Foo): void {
  ...
}

foo(() => ({
  a: true,
  b: false // No compile error (BAD!)
}))

foo((): Foo => ({
  a: true,
  b: false // Compile error (GOOD!)
}))

Why does this occur?

Without a return type, the lambda's return type will be inferred to be a supertype of the type you actually want. This means no excess property checking will occur, as the inferred return type will automatically contain every property you specify. The resulting lambda instance will then be silently assignable to any lambda variable whose return type is a subtype, since lambda return types are covariant.

In the example above, the first lambda instance (line 7) is inferred as type () => Foo & { b: boolean }, which is subsequently assigned to the variable callback: () => Foo on line 3, which is allowed because Foo & { b: boolean } is a supertype of Foo. In line 12 we fix this by preventing TypeScript from inferring a supertype.

Credits

The following article was very useful when writing this plugin:

Writing custom TypeScript ESLint rules: How I learned to love the AST

License

MIT