# ESLint v10.14.0: п’ять правил отримали тихі, але важливі фікси > ESLint v10.14.0 виправляє edge-case баги в func-name-matching, no-invalid-this, no-restricted-globals, object-shorthand і yoda та підтягує вразливу залежність minimatch. - Автор: Юра Скиба (https://cookiesoftware.io) - Опубліковано: 2026-10-31 - Категорія: JavaScript і TypeScript - Canonical: https://cookiesoftware.io/blog/eslint-10-14-0-bugfix-release --- 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: ```ts // 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 перед комітом](/blog/ai-kod-chek-list-perevirky). ## Чесні обмеження цього релізу Це не той реліз, який треба ставити в пріоритет на найближчий спринт. Фікси точкові, і якщо в проєкті немає 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-хаосу](/blog/github-actions-lockfiles). Документаційна зміна з `--rulesdir` на virtual plugin – це оновлення прикладу в документації, а не заявлена зміна поведінки самого флага. Не варто читати це як «rulesdir видалили» – джерело каже лише про оновлення документаційного прикладу кастомних правил. ## Коли справді варто оновлюватись Онови зараз, якщо: твій CI перевіряє lockfile на вразливості і minimatch у звіті вже підсвічений; у кодовій базі є класи з accessor-полями, super-методи поруч з object-shorthand, або активний yoda. В інших випадках – постав апдейт у звичайну чергу разом із наступним плановим оновленням залежностей, без паніки. Головне – не плутати цей реліз із приводом ігнорувати ширшу картину: якщо команда досі на ESLint v9.x, саме зараз момент спланувати міграцію, бо вона вже не отримує жодних security-патчів. Апдейт до 10.14.0 для тих, хто вже на десятці, – справа пʼяти хвилин і одного прогону тестів; перехід з дев’ятки – окремий таск, який варто закласти в спринт, а не відкладати до першого інциденту.