ESLint v10.14.0 вийшов 30 жовтня 2026 року, і це звичайний minor-реліз без гучних нових правил: пʼять правил отримали фікси edge-case поведінки, одна залежність підтягнута через вразливість, а решта – документація й chore-коміти. Якщо шукаєш привід терміново зупиняти спринт – його тут немає. Але якщо твій CI покладається на автофікс або ти використовуєш якесь із оновлених правил – diff після апдейту варто подивитись уважно.

Чому це взагалі має тебе хвилювати

Лінтер – це той інструмент, якому ти довіряєш мовчки: налаштував один раз, підключив до CI, і він просто працює у фоні. Проблема в тому, що саме тому баги в правилах ESLint живуть довго й непомітно – доки хтось не зловить крash на accessor-полі класу або не побачить, що автофікс згенерував код, який навіть не парситься.

Другий момент – ESLint v9.x уже офіційно end-of-life з 6 серпня 2026 року і більше не отримує підтримки. Якщо команда досі сидить на дев’ятці, це вже не питання «нема часу оновитись», а питання відсутності будь-яких майбутніх security-патчів для лінтера, який у більшості проєктів запускається на кожен pull request.

Що саме полагодили в 10.14.0

За описом релізу, оновлення торкнулось пʼяти правил, у кожного – свій edge case:

  • func-name-matching – виправили обробку property descriptor, тобто правило тепер коректніше розпізнає імена функцій у специфічних конфігураціях властивостей.
  • no-invalid-this – правило більше не крашиться на accessor-полях класів без ініціалізатора. Це саме той тип бага, який зʼявляється не одразу, а щойно хтось у команді напише клас із get/set-полем без значення за замовчуванням.
  • no-restricted-globals – пофіксили краш, коли глобальний обʼєкт використовується як значення властивості, а не напряму.
  • object-shorthand – автофікс більше не ламає super-методи. До фіксу спроба «скоротити» метод, який звертається до super, могла згенерувати невалідний код.
  • yoda – виправили невалідний автофікс, коли правило спрацьовує на самому початку стейтменту.

Окремо йдуть два фікси, які не про правила, а про надійність самого парсера: коректна обробка LS, PS та порожніх hashbang-коментарів.

Із security-боку – мабуть, найважливіший рядок у всьому списку: вимога на minimatch 10.2.6, щоб прибрати вразливий brace-expansion у ланцюжку залежностей. ESLint тут поводиться відповідально – не чекає, доки хтось зловить CVE в проді, а піднімає залежність у рамках звичайного minor-релізу.

У документації прибрали згадку про комерційну підтримку Tidelift, оновили приклад для кастомних правил, замінивши старий підхід через --rulesdir на приклад із virtual plugin, і підтягнули опис loadESLint() під актуальну поведінку в v10.

Де на практиці ти міг зловити ці баги

Конфігурація ESLint із пʼятьма згаданими правилами виглядає приблизно так – нічого екзотичного, звичайний flat config:

// eslint.config.js
import js from "@eslint/js";

export default [
  js.configs.recommended,
  {
    rules: {
      "func-name-matching": "error",
      "no-invalid-this": "error",
      "no-restricted-globals": ["error", "event", "fdescribe"],
      "object-shorthand": "error",
      "yoda": "error",
    },
  },
];

Якщо в проєкті є класи з accessor-полями без значення за замовчуванням, а no-invalid-this увімкнений – до фіксу це міг бути крash лінтера прямо посеред CI, а не акуратне попередження. Те саме з object-shorthand: якщо в кодовій базі є методи, що викликають super, а хтось запускав eslint --fix на весь репозиторій, варто перевірити, чи не зʼявився невалідний код у старих комітах до цього релізу.

Умовно: якщо в команді є звичка ганяти --fix в pre-commit хуку без ручного рев’ю диффу, саме такі edge cases і пролазять непомітно в історію git. До речі, цю ж логіку – не довіряти автоматичним правкам коду без перевірки – варто застосовувати і до AI-генерованого коду, про що детальніше в чеклісті перевірки коду від AI перед комітом.

Чесні обмеження цього релізу

Це не той реліз, який треба ставити в пріоритет на найближчий спринт. Фікси точкові, і якщо в проєкті немає accessor-полів без ініціалізатора, методів з super поруч із object-shorthand, чи yoda-умов на початку стейтменту – ти просто не зустрінешся з цими багами на практиці.

Апдейт minimatch до 10.2.6 – інша історія: якщо у вас в CI є pinned lockfile, оновлення ESLint автоматично не підтягне транзитивну залежність сам по собі, доки lockfile не перегенерується. Для команд, які серйозно підходять до supply-chain безпеки в pipeline, це варто тримати в голові поруч із іншими практиками pinning-у – про сам підхід до lockfiles добре розказано в матеріалі про GitHub Actions і supply-chain security без pin-хаосу.

Документаційна зміна з --rulesdir на virtual plugin – це оновлення прикладу в документації, а не заявлена зміна поведінки самого флага. Не варто читати це як «rulesdir видалили» – джерело каже лише про оновлення документаційного прикладу кастомних правил.

Коли справді варто оновлюватись

Онови зараз, якщо: твій CI перевіряє lockfile на вразливості і minimatch у звіті вже підсвічений; у кодовій базі є класи з accessor-полями, super-методи поруч з object-shorthand, або активний yoda. В інших випадках – постав апдейт у звичайну чергу разом із наступним плановим оновленням залежностей, без паніки.

Головне – не плутати цей реліз із приводом ігнорувати ширшу картину: якщо команда досі на ESLint v9.x, саме зараз момент спланувати міграцію, бо вона вже не отримує жодних security-патчів. Апдейт до 10.14.0 для тих, хто вже на десятці, – справа пʼяти хвилин і одного прогону тестів; перехід з дев’ятки – окремий таск, який варто закласти в спринт, а не відкладати до першого інциденту.