ESLint v10.14.0: точечные исправления правил и корректная обработка дескрипторов

Когда статический анализатор кода падает посреди ночного прогона CI с непонятным стектрейсом, разработчик обычно винит сложные типы или кривую стороннюю зависимость. Но иногда причина оказывается куда прозаичнее: сам линтер споткнулся о редкую синтаксическую конструкцию ECMAScript, о которой забыли авторы правил.

В конце октября команда проекта выпустила минорный релиз ESLint v10.14.0, целиком посвященный полировке стабильности синтаксического анализа и исправлению коварных ошибок в механизмах автоматического исправления кода (autofix).

Опасный автофикс в object-shorthand

Самый важный багфикс этого релиза затронул правило object-shorthand (коммит cb2b9d4, PR #21323). В JavaScript методы объектов имеют специальную привязку к прототипу для вызова родительских методов через ключевое слово super. Если разработчик объявлял метод классическим способом, линтер с включенным автофиксом пытался преобразовать его в короткое стрелочное свойство:

// До исправления в ESLint v10.14.0:
// Попытка автофикса object-shorthand могла превратить валидный метод:
const childComponent = {
  render() {
    return super.render();
  }
};

// ...вот в такую синтаксически невалидную конструкцию:
const brokenComponent = {
  render: () => {
    // Ошибка во время выполнения: SyntaxError: super keyword unexpected here
    return super.render();
  }
};

Стрелочные функции не имеют собственного контекста this и привязки super, поэтому такой «полезный» автофикс намертво ломал исполнение кода прямо в рантайме. В версии 10.14.0 анализатор научился проверять наличие обращений к super перед трансформацией синтаксического дерева.

Аксессоры, дескрипторы и безопасность

Второе критическое исправление коснулось правила no-invalid-this (коммит 6194939, PR #21442). С приходом спецификации декораторов и авто-аксессоров классов (accessor foo;) парсер линтера падал в аварийный отказ при встрече полей классов без явного значения инициализатора. Теперь синтаксис аксессоров анализируется абсолютно штатно.

Кроме того, правило func-name-matching научилось корректно считывать имена функций, переданные через дескрипторы свойств объектов (Object.defineProperty, свойства value, get, set), а минимальная версия служебного пакета minimatch была поднята до 10.2.6 для закрытия потенциальной уязвимости в обработке путей.

Давай посмотрим, как выглядит современный плоский конфигурационный файл eslint.config.js с настройкой этих правил:

import js from "@eslint/js";

export default [
  js.configs.recommended,
  {
    files: ["**/*.js", "**/*.mjs"],
    rules: {
      "object-shorthand": ["error", "always", { avoidQuotes: true }],
      "func-name-matching": ["error", "always"],
      "no-invalid-this": "error",
      "yoda": ["error", "never"]
    }
  }
];

Кстати, если ты следишь за эволюцией экосистемы инструментов и фреймворков вроде Preact 11, то наверняка знаешь, насколько чистота сборки и отсутствие ложных предупреждений линтера влияют на скорость прохождения проверок в пайплайнах.

Обновление полностью обратно совместимо в рамках ветки v10.x. Для обновления в проекте достаточно выполнить стандартную команду npm install eslint@10.14.0 --save-dev или pnpm update eslint.