Вклад в основные правила

Основные правила ESLint — это правила, включенные в пакет ESLint.

Документация по написанию правил

Для получения полной информации о написании правил обратитесь к Пользовательским правилам. И пользовательские, и основные правила имеют одинаковый API. Основное различие между основными и пользовательскими правилами заключается в следующем:

1. Основные правила включены в пакет eslint.
2. Основные правила должны соответствовать соглашениям, описанным на этой странице.

Структура файлов

Каждое основное правило в ESLint имеет три файла, именованных в соответствии с его идентификатором (например, no-extra-semi).

• в каталоге lib/rules: исходный файл (например, no-extra-semi.js)
• в каталоге tests/lib/rules: тестовый файл (например, no-extra-semi.js)
• в каталоге docs/src/rules: файл документации в формате Markdown (например, no-extra-semi.md)

Важно: Если вы отправляете основное правило в репозиторий ESLint, вы обязаны следовать соглашениям, описанным ниже.

Вот базовый формат исходного файла для правила:

/**
 * @fileoverview Rule to disallow unnecessary semicolons
 * @author Nicholas C. Zakas
 */

"use strict";

//------------------------------------------------------------------------------
// Rule Definition
//------------------------------------------------------------------------------

/** @type {import('../shared/types').Rule} */
module.exports = {
    meta: {
        type: "suggestion",

        docs: {
            description: "disallow unnecessary semicolons",
            recommended: true,
            url: "https://eslint.org/docs/rules/no-extra-semi"
        },
        fixable: "code",
        schema: [] // no options
    },
    create: function(context) {
        return {
            // callback functions
        };
    }
};

Тесты модулей правил

Каждое интегрированное правило для ядра ESLint должно иметь набор модульных тестов, которые должны быть отправлены вместе с ним, чтобы быть принятым. Тестовый файл имеет то же имя, что и исходный файл, но находится в tests/lib/. Например, если исходный файл правила — lib/rules/foo.js, то тестовый файл должен быть tests/lib/rules/foo.js.

ESLint предоставляет утилиту RuleTester, чтобы упростить написание тестов для правил.

Тестирование производительности

Для поддержания эффективного и незаметного процесса линтера полезно проверять влияние производительности новых правил или изменений существующих правил.

Чтобы узнать, как профилировать производительность отдельных правил, обратитесь к разделу Профилирование производительности правил в документации по пользовательским правилам.

При разработке в репозитории ESLint команда npm run perf предоставляет общий обзор времени выполнения ESLint со всеми активными основными правилами.

$ git checkout main
Switched to branch 'main'

$ npm run perf
CPU Speed is 2200 with multiplier 7500000
Performance Run #1:  1394.689313ms
Performance Run #2:  1423.295351ms
Performance Run #3:  1385.09515ms
Performance Run #4:  1382.406982ms
Performance Run #5:  1409.68566ms
Performance budget ok:  1394.689313ms (limit: 3409.090909090909ms)

$ git checkout my-rule-branch
Switched to branch 'my-rule-branch'

$ npm run perf
CPU Speed is 2200 with multiplier 7500000
Performance Run #1:  1443.736547ms
Performance Run #2:  1419.193291ms
Performance Run #3:  1436.018228ms
Performance Run #4:  1473.605485ms
Performance Run #5:  1457.455283ms
Performance budget ok:  1443.736547ms (limit: 3409.090909090909ms)

Соглашения об именовании правил

Соглашения об именовании правил ESLint следующие:

• Используйте дефисы между словами.
• Если ваше правило только запрещает что-либо, добавьте префикс no-, например no-eval для запрета eval() и no-debugger для запрета debugger.
• Если ваше правило требует включения чего-либо, используйте короткое имя без специального префикса.