Skip to main content

prefer-readonly-parameter-types

Require function parameters to be typed as readonly to prevent accidental mutation of inputs.

💭

This rule requires type information to run.

Mutating function arguments can lead to confusing, hard to debug behavior. Whilst it's easy to implicitly remember to not modify function arguments, explicitly typing arguments as readonly provides clear contract to consumers. This contract makes it easier for a consumer to reason about if a function has side-effects.

This rule allows you to enforce that function parameters resolve to readonly types. A type is considered readonly if:

  • it is a primitive type (string, number, boolean, symbol, or an enum),
  • it is a function signature type,
  • it is a readonly array type whose element type is considered readonly.
  • it is a readonly tuple type whose elements are all considered readonly.
  • it is an object type whose properties are all marked as readonly, and whose values are all considered readonly.
.eslintrc.cjs
module.exports = {
  "rules": {
    "@typescript-eslint/prefer-readonly-parameter-types": "error"
  }
};

Try this rule in the playground ↗

Examples​

function array1(arg: string[]) {} // array is not readonly
function array2(arg: readonly string[][]) {} // array element is not readonly
function array3(arg: [string, number]) {} // tuple is not readonly
function array4(arg: readonly [string[], number]) {} // tuple element is not readonly
// the above examples work the same if you use ReadonlyArray<T> instead

function object1(arg: { prop: string }) {} // property is not readonly
function object2(arg: { readonly prop: string; prop2: string }) {} // not all properties are readonly
function object3(arg: { readonly prop: { prop2: string } }) {} // nested property is not readonly
// the above examples work the same if you use Readonly<T> instead

interface CustomArrayType extends ReadonlyArray<string> {
  prop: string; // note: this property is mutable
}
function custom1(arg: CustomArrayType) {}

interface CustomFunction {
  (): void;
  prop: string; // note: this property is mutable
}
function custom2(arg: CustomFunction) {}

function union(arg: string[] | ReadonlyArray<number[]>) {} // not all types are readonly

// rule also checks function types
interface Foo {
  (arg: string[]): void;
}
interface Foo {
  new (arg: string[]): void;
}
const x = { foo(arg: string[]): void {} };
function foo(arg: string[]);
type Foo = (arg: string[]) => void;
interface Foo {
  foo(arg: string[]): void;
}
Open in Playground

Options​

This rule accepts the following options:

type Options = [
  {
    /** An array of type specifiers to ignore. */
    allow?: (
      | {
          from: 'file';
          name: [string, ...string[]] | string;
          path?: string;
        }
      | {
          from: 'lib';
          name: [string, ...string[]] | string;
        }
      | {
          from: 'package';
          name: [string, ...string[]] | string;
          package: string;
        }
      | string
    )[];
    /** Whether to check class parameter properties. */
    checkParameterProperties?: boolean;
    /** Whether to ignore parameters which don't explicitly specify a type. */
    ignoreInferredTypes?: boolean;
    /** Whether to treat all mutable methods as though they are readonly. */
    treatMethodsAsReadonly?: boolean;
  },
];

const defaultOptions: Options = [
  {
    allow: [],
    checkParameterProperties: true,
    ignoreInferredTypes: false,
    treatMethodsAsReadonly: false,
  },
];

allow​

An array of type specifiers to ignore. Some complex types cannot easily be made readonly, for example the HTMLElement type or the JQueryStatic type from @types/jquery. This option allows you to globally disable reporting of such types.

This option takes the shared TypeOrValueSpecifier format.

Examples of code for this rule with:

{
  "allow": [
    { "from": "file", "name": "Foo" },
    { "from": "lib", "name": "HTMLElement" },
    { "from": "package", "name": "Bar", "package": "bar-lib" }
  ]
}
interface ThisIsMutable {
  prop: string;
}

interface Wrapper {
  sub: ThisIsMutable;
}

interface WrapperWithOther {
  readonly sub: Foo;
  otherProp: string;
}

// Incorrect because ThisIsMutable is not readonly
function fn1(arg: ThisIsMutable) {}

// Incorrect because Wrapper.sub is not readonly
function fn2(arg: Wrapper) {}

// Incorrect because WrapperWithOther.otherProp is not readonly and not in the allowlist
function fn3(arg: WrapperWithOther) {}
Open in Playground
import { Foo } from 'some-lib';
import { Bar } from 'incorrect-lib';

interface HTMLElement {
  prop: string;
}

// Incorrect because Foo is not a local type
function fn1(arg: Foo) {}

// Incorrect because HTMLElement is not from the default library
function fn2(arg: HTMLElement) {}

// Incorrect because Bar is not from "bar-lib"
function fn3(arg: Bar) {}
Open in Playground

checkParameterProperties​

Whether to check class parameter properties. Because parameter properties create properties on the class, it may be undesirable to force them to be readonly.

Examples of code for this rule with {checkParameterProperties: true}:

class Foo {
  constructor(private paramProp: string[]) {}
}
Open in Playground

Examples of correct code for this rule with {checkParameterProperties: false}:

class Foo {
  constructor(
    private paramProp1: string[],
    private paramProp2: readonly string[],
  ) {}
}
Open in Playground

ignoreInferredTypes​

Whether to ignore parameters which don't explicitly specify a type. This may be desirable in cases where an external dependency specifies a callback with mutable parameters, and manually annotating the callback's parameters is undesirable.

Examples of code for this rule with {ignoreInferredTypes: true}:

import { acceptsCallback, CallbackOptions } from 'external-dependency';

acceptsCallback((options: CallbackOptions) => {});
Open in Playground
external-dependency.d.ts
export interface CallbackOptions {
  prop: string;
}
type Callback = (options: CallbackOptions) => void;
type AcceptsCallback = (callback: Callback) => void;

export const acceptsCallback: AcceptsCallback;

treatMethodsAsReadonly​

Whether to treat all mutable methods as though they are readonly. This may be desirable when you are never reassigning methods.

Examples of code for this rule with {treatMethodsAsReadonly: false}:

type MyType = {
  readonly prop: string;
  method(): string; // note: this method is mutable
};
function foo(arg: MyType) {}
Open in Playground

Examples of correct code for this rule with {treatMethodsAsReadonly: true}:

type MyType = {
  readonly prop: string;
  method(): string; // note: this method is mutable
};
function foo(arg: MyType) {}
Open in Playground

When Not To Use It​

If your project does not attempt to enforce strong immutability guarantees of parameters, you can avoid this rule.

This rule is very strict on what it considers mutable. Many types that describe themselves as readonly are considered mutable because they have mutable properties such as arrays or tuples. To work around these limitations, you might need to use the rule's options. In particular, the allow option can explicitly mark a type as readonly.

Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.

See Troubleshooting > Linting with Type Information > Performance if you experience performance degredations after enabling type checked rules.

Resources​