Skip to main content

no-unsafe-member-access

Disallow member access on a value with type any.

✅

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

💭

This rule requires type information to run, which comes with performance tradeoffs.

The any type in TypeScript is a dangerous "escape hatch" from the type system. Using any disables many type checking rules and is generally best used only as a last resort or when prototyping code.

Despite your best intentions, the any type can sometimes leak into your codebase. Accessing a member of an any-typed value creates a potential type safety hole and source of bugs in your codebase.

This rule disallows member access on any variable that is typed as any.

eslint.config.mjs
export default tseslint.config({
  rules: {
    "@typescript-eslint/no-unsafe-member-access": "error"
  }
});

Try this rule in the playground ↗

Examples​

declare const anyVar: any;
declare const nestedAny: { prop: any };

anyVar.a;
anyVar.a.b;
anyVar['a'];
anyVar['a']['b'];

nestedAny.prop.a;
nestedAny.prop['a'];

const key = 'a';
nestedAny.prop[key];

// Using an any to access a member is unsafe
const arr = [1, 2, 3];
arr[anyVar];
nestedAny[anyVar];
Open in Playground

Options​

This rule accepts the following options:

type Options = [
  {
    /** Whether to allow `?.` optional chains on `any` values. */
    allowOptionalChaining?: boolean;
  },
];

const defaultOptions: Options = [{ allowOptionalChaining: false }];

allowOptionalChaining​

Whether to allow ?. optional chains on any values. Default: false.

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

declare const outer: any;

outer.inner;
outer.middle.inner;
Open in Playground
caution

We only recommend using allowOptionalChaining to help transition an existing project towards fully enabling no-unsafe-member-access. Optional chaining makes it safer than normal property accesses in that you won't get a runtime error if the parent value is null or undefined. However, it still results in an any-typed value, which is unsafe.

When Not To Use It​

If your codebase has many existing anys or areas of unsafe code, it may be difficult to enable this rule. It may be easier to skip the no-unsafe-* rules pending increasing type safety in unsafe areas of your project. You might consider using ESLint disable comments for those specific situations instead of completely disabling this rule.

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 degradations after enabling type checked rules.

Resources​