Незадолго до этого, в моем обычном стремлении открыть новые репозитории с открытым исходным кодом и найти место, где я могу учиться, совершенствоваться и вносить свой вклад, я наткнулся на treeherder.

Treeherder — Система управления данными CI для проектов Mozilla.

Репозиторий, в который кто-то может внести свой вклад, особенно если вы только начинаете работать с открытым исходным кодом.

К счастью, были некоторые проблемы, которые нуждались в помощи! Вот куда я вхожу!

TL;DR — ES-Lint — это подключаемая утилита для линтинга для JavaScript и JSX.

ESLint — это инструмент для выявления шаблонов, обнаруженных в коде ECMAScript/JavaScript, и составления отчетов о них, цель которого — сделать код более согласованным и избежать ошибок. Во многом он похож на JSLint и JSHint за некоторыми исключениями:

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

Чтобы узнать больше о ES-Lint — https://eslint.org/docs/user-guide/getting-started

Вот в чем была проблема:
повторно включить несколько правил линтинга — пакет № 1.

Удалите эти строки:

'class-methods-use-this': 'off',
    'consistent-return': 'off',
    'default-case': 'off',

и убедитесь, что yarn lint проходит, прежде чем открывать PR.

Удаление этих строк из lint-файла — задача для новичков, но сделать так, чтобы все тестовые случаи проходили через yarn lint — о боже, после удаления этих строк 50 тестовых случаев не прошли, я знал, что это займет некоторое время. .

Первым шагом, как всегда, было чтение документации о том, что и по какому правилу делается. Давайте рассмотрим это шаг за шагом.

Метод класса, используй это

Принудительно использовать методы класса this (методы класса используют это)

Если метод класса не использует this, его можно иногда превратить в статическую функцию. Если вы преобразуете метод в статическую функцию, экземпляры класса, которые вызывают этот конкретный метод, также должны быть преобразованы в статический вызов (MyClass.callStaticMethod())

Можно иметь метод класса, который не использует this, например:

class A {
    constructor() {
        this.a = "hi";
    }
print() {
        console.log(this.a);
    }
sayHi() {
        console.log("hi");
    }
}
let a = new A();
a.sayHi(); // => "hi"

В приведенном выше примере метод sayHi не использует this, поэтому мы можем сделать его статическим методом:

class A {
    constructor() {
        this.a = "hi";
    }
print() {
        console.log(this.a);
    }
static sayHi() {
        console.log("hi");
    }
}
A.sayHi(); // => "hi"

Всего в коде было 11 случаев, когда я нашел метод внутри класса, в котором не использовалось ключевое слово this. И не самое главное было выяснить, как их изменить, потому что у некоторых из них просто не было никаких свойств.

Чтобы буквально пройти некоторые тестовые случаи:
я включил строку:

это.для этого = ноль; // Просто добавляем, чтобы использовать это

Тем не менее, я каким-то образом смог внести все эти изменения и пройти ворсовые тесты!

Постоянный возврат

требуют, чтобы операторы return либо всегда, либо никогда не указывали значения (согласованный возврат)

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

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

  • он не выполняет оператор return перед выходом
  • он выполняет return, который явно не указывает значение
  • он выполняет return undefined
  • он выполняет return void, за которым следует выражение (например, вызов функции)
  • он выполняет return, за которым следует любое другое выражение, которое оценивается как undefined

Если какие-либо пути кода в функции явно возвращают значение, но некоторые пути кода не возвращают значение явно, это может быть опечаткой, особенно в большой функции. В следующем примере:

  • путь кода через функцию возвращает логическое значение true
  • другой путь кода не возвращает значение явно, поэтому неявно возвращает undefined
function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

Сведения о правиле

Это правило требует, чтобы операторы return либо всегда, либо никогда не указывали значения. Это правило игнорирует определения функций, имя которых начинается с заглавной буквы, потому что конструкторы (при вызове с помощью оператора new) неявно возвращают созданный объект, если они не возвращают другой объект явно.

Примеры неправильного кода для этого правила:

/*eslint consistent-return: "error"*/
function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}
function doSomething(condition) {
    if (condition) {
        return true;
    }
}

Примеры правильного кода для этого правила:

/*eslint consistent-return: "error"*/
function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}
function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }
this.a = 0;Default Case
}

Итак, в соответствии с этим правилом все методы и функции должны последовательно возвращать или не возвращать значение в конце метода или функции!

Вот тут-то и возникла проблема!

Невероятное количество тестовых случаев 39 провалилось после включения последовательного возврата.
Теперь вы не можете просто понять, что может возвращать функция, очевидно, только после того, как вы правильно прочитаете всю функцию и прочитаете, что она делает.

Что ж, я сделал это и добавил необходимые операторы возврата везде, где мог.

Но все же, чтобы эта штука работала, в некоторых случаях я просто писал,

return null

Что ж, это помогло.

К следующему правилу.

Случай по умолчанию

Требовать регистр по умолчанию в операторах Switch (регистр по умолчанию)

Некоторые соглашения о коде требуют, чтобы все операторы switch имели регистр default, даже если регистр по умолчанию пуст, например:

switch (foo) {
    case 1:
        doSomething();
        break;
case 2:
        doSomething();
        break;
default:
        // do nothing
}

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

Другие соглашения о коде позволяют пропускать регистр default, если есть комментарий, указывающий на то, что это упущение намеренно, например:

switch (foo) {
    case 1:
        doSomething();
        break;
case 2:
        doSomething();
        break;
// no default
}

Еще раз, цель здесь состоит в том, чтобы показать, что разработчик хотел, чтобы не было поведения по умолчанию.

Сведения о правиле

Это правило направлено на требование регистра default в операторах switch. При желании вы можете включить // no default после последнего case, если нет default регистра. Комментарий может быть в любом желаемом регистре, например // No Default.

Примеры неправильного кода для этого правила:

/*eslint default-case: "error"*/
switch (a) {
    case 1:
        /* code */
        break;
}

Примеры правильного кода для этого правила:

/*eslint default-case: "error"*/
switch (a) {
    case 1:
        /* code */
        break;
default:
        /* code */
        break;
}
switch (a) {
    case 1:
        /* code */
        break;
// no default
}
switch (a) {
    case 1:
        /* code */
        break;
// No Default
}

Итак, самое простое из трех, это правило гласит, что каждый оператор switch должен иметь в конце вариант по умолчанию.
Только 4 тестовых примера не прошли при включении этого правила, и просто добавление варианта по умолчанию , даже без кода сделал свое дело.

Я знал, что есть несколько мест, где я сделал некоторые вещи, чтобы просто пройти тестовые случаи, и я чувствовал себя немного смешно, создавая PR для этой проблемы, но оказалось:

К моему удивлению, пришел еще один из этих замечательных наставников и еще раз проверил мой код!

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

Что я узнал — до сих пор —

  1. Как включать и отключать правила в ES Lint
  2. Почему правила ES Lint так важны
  3. После включения каждого правила прочтите его документацию и поймете, что оно на самом деле делает.
  4. Внесение необходимых изменений, чтобы тестовые случаи по-прежнему проходили!

Мне понравилось работать над этим вопросом, было приятно!

Написано с любовью,
Ришаб Будхираджа