Правила для строгого режима

Строгий режим JavaScript (strict mode) меняет поведение интерпретатора, устраняя часть исторических особенностей языка и превращая многие потенциальные ошибки в исключения. В экосистеме ESLint строгий режим рассматривается как обязательная часть базовой гигиены кода, однако его реализация отличается от ранних версий линтера и тесно связана с модульной системой ECMAScript.

В современном JavaScript строгий режим включается либо директивой "use strict", либо автоматически в модулях ES (import / export). ESLint не является исполнителем кода, поэтому он не «включает» строгий режим напрямую, а проверяет корректность его применения и предотвращает использование конструкций, несовместимых с ним.

Историческая роль правила strict

Ранее ESLint включал правило strict, которое контролировало наличие директивы строгого режима в файлах и функциях. Оно поддерживало несколько режимов:

  • safe — требовал строгий режим только в ES5-коде
  • global — требовал "use strict" в верхнем уровне файлов
  • function — требовал директиву в каждой функции

Со временем это правило утратило актуальность. Причина заключается в том, что:

  • ES6-модули всегда работают в строгом режиме
  • современные конфигурации не нуждаются в ручном контроле директивы
  • линтеры сместили фокус на конкретные ошибки строгого режима, а не на сам факт его включения

В результате правило strict было признано устаревшим и больше не используется в новых конфигурациях ESLint.

Автоматический строгий режим в ECMAScript модулях

ESLint учитывает важную особенность языка: любой файл, объявленный как ES-модуль, автоматически интерпретируется в строгом режиме.

К таким файлам относятся:

  • файлы с import / export
  • модули с указанием "type": "module" в package.json

Это означает, что в подобных файлах:

  • запрещено использование with
  • this в верхнем контексте не привязан к глобальному объекту
  • запрещены дублирующиеся параметры функций
  • недоступны некоторые устаревшие возможности языка

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

Основные ESLint-правила, связанные со строгим режимом

Вместо управления директивой строгого режима современный ESLint использует набор правил, которые отражают его ограничения.

no-eval

Запрещает использование eval, которое в строгом режиме становится более ограниченным и потенциально опасным.

Ключевые особенности:

  • блокирует динамическое выполнение строкового кода
  • снижает риск внедрения вредоносного кода
  • упрощает статический анализ

no-implied-eval

Запрещает неявные формы eval, включая:

  • setTimeout("code")
  • setInterval("code")
  • new Function("code")

В строгом режиме подобные конструкции ведут себя непредсказуемо и ухудшают оптимизацию.

no-caller

Запрещает доступ к arguments.callee и arguments.caller, которые:

  • недоступны в строгом режиме
  • ломают оптимизации движка
  • создают скрытые зависимости между функциями

no-unsafe-negation / no-global-assign

Хотя эти правила не являются прямыми следствиями строгого режима, они логически продолжают его идею: устранение неявного поведения и глобальных побочных эффектов.

Отличия строгого режима, которые учитывает ESLint

Строгий режим влияет не только на синтаксис, но и на семантику выполнения кода. ESLint учитывает это через статические проверки.

Запрет неявных глобальных переменных

В строгом режиме присваивание несуществующей переменной вызывает ошибку. ESLint реализует это через:

  • no-undef
  • no-global-assign

Эти правила предотвращают создание глобальных переменных без объявления.

Ограничение дублирующихся параметров

function sum(a, a, b) {}

В строгом режиме такая функция вызывает исключение. ESLint фиксирует это через:

  • no-dupe-args (встроенная проверка parser’а)

Поведение this

В строгом режиме значение this в обычных функциях равно undefined, если вызов не привязан явно.

ESLint не проверяет значение this напрямую, но помогает выявлять проблемные места через:

  • no-invalid-this
  • func-names
  • consistent-this

Конфигурация строгого поведения через parserOptions

Современные конфигурации ESLint используют parserOptions для описания версии ECMAScript и типа модулей:

export default {
  parserOptions: {
    ecmaVersion: 2022,
    sourceType: "module"
  }
}

При таком описании:

  • строгий режим включается автоматически
  • правило strict не требуется
  • анализ ориентируется на современные синтаксические ограничения

Взаимодействие строгого режима и среды выполнения

Различные среды накладывают дополнительные ограничения:

Node.js

  • CommonJS-файлы не всегда работают в строгом режиме по умолчанию
  • ES-модули всегда строгие
  • ESLint конфигурации часто разделяют правила для cjs и esm

Браузер

  • глобальный скрипт может работать без строгого режима
  • наличие "use strict" влияет на поведение всех функций внутри файла
  • ESLint не различает среду выполнения напрямую, но использует env настройки
export default {
  env: {
    browser: true,
    es2021: true
  }
}

Типовые ошибки, связанные со строгим режимом

Необъявленные переменные

value = 10;

В строгом режиме это приводит к ошибке. ESLint предотвращает это через no-undef.

Удаление переменных

delete x;

В строгом режиме запрещено удалять переменные. ESLint фиксирует подобные конструкции через no-delete-var.

Дублирование ключей

const obj = {
  a: 1,
  a: 2
};

Строгий режим не допускает такие случаи, ESLint проверяет через no-dupe-keys.

Практика применения строгих ограничений через ESLint

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

  • базовый набор eslint:recommended
  • дополнительные ограничения безопасности
  • правила предотвращения неявного поведения

Пример конфигурационного слоя:

export default {
  rules: {
    "no-undef": "error",
    "no-eval": "error",
    "no-implied-eval": "error",
    "no-caller": "error",
    "no-dupe-keys": "error"
  }
}

Такой набор формирует поведение, эквивалентное строгому режиму, но на уровне статического анализа, а не исполнения.

Эволюция строгого режима в экосистеме линтинга

Со временем строгий режим перестал быть отдельной сущностью в конфигурациях ESLint. Его функции распределились между:

  • синтаксическим анализатором (parser)
  • правилами безопасности
  • модульной системой ECMAScript

Это позволило устранить дублирование проверок и сосредоточить внимание на конкретных классах ошибок, а не на декларативной директиве "use strict".

Оглавление