This rule raises an issue when properties are assigned to this in a constructor instead of being declared as class fields.

Why is this an issue?

Modern JavaScript supports class field declarations, which provide a cleaner and more readable way to define class properties compared to constructor assignments.

When properties are assigned in constructors using this.property = value, the code becomes more verbose and harder to read. Class field declarations offer several advantages:

• Better readability: Property declarations are immediately visible at the class level
• Reduced boilerplate: No need for constructor code when only setting default values
• Consistent syntax: Aligns with modern JavaScript standards and practices
• Clearer intent: Makes it obvious which properties belong to the class

Class field declarations also work with both public and private properties (using the # prefix), providing a unified approach to property definition.

What is the potential impact?

This issue affects code maintainability and readability. While it doesn’t cause runtime errors, using outdated patterns makes the codebase harder to understand and maintain. Teams working with modern JavaScript expect to see class field syntax, and constructor-based assignments can appear outdated or unnecessarily verbose.

How to fix?

Move simple property assignments from the constructor to class field declarations. This makes the code more concise and follows modern JavaScript conventions.

Non-compliant code example

class Foo {
  constructor() {
    this.foo = 'foo'; // Noncompliant
  }
}

Compliant code example

class Foo {
  foo = 'foo';
}

Documentation

• eslint-plugin-unicorn - Rule prefer-class-fields
• MDN - Public class fields - Documentation on public class field declarations in JavaScript
• MDN - Private class features - Documentation on private class fields and methods
• ESLint - no-useless-constructor - Complementary rule to remove empty constructors after applying this fix