Tslint: Запрос функции: разрешить исключение файлов для определенного правила

Почему бы вам просто не использовать:

/* tslint:disable:class-name */
// your generated file here

Это не работает?

Это действительно могло быть использовано для его работы, но я подал этот запрос функции, чтобы избежать изменения генератора TypeScript (или усложнить процесс генерации, добавив сгенерированные файлы с подсказками tslint).
Использование подстановочных знаков также может быть полезно для декларативного применения определенных правил только к определенным типам источников (main / unitTests / e2eTests) из конфигурации tslint, а не к каждому файлу в отдельности.

Что ты думаешь?

Если вы не хотите помещать комментарии в файл, просто не передавайте файл в tslint для линтинга, не так ли?

Кажется слишком тяжелым добавлять дополнительные параметры где-либо еще, когда есть как минимум два средства достижения (частичного) исключения файлов.

Если вы не хотите помещать комментарии в файл, просто не передавайте файл в tslint для линтинга, не так ли?

Это именно то, что я сделал, но теперь ни одно из правил не проверяется на исключенные файлы.

Кажется слишком тяжелым добавлять дополнительные параметры где-либо еще, когда есть как минимум два средства достижения (частичного) исключения файлов.

Да, это то, что я ожидал в качестве ответа;) У меня тоже были некоторые сомнения - по крайней мере, насчет реализации (которую я старался сделать как можно проще).

На самом деле, если бы это было реализовано, было бы полезно, если бы вы могли определить константы для шаблонов включения и исключения, поэтому вам не нужно копировать один и тот же шаблон включения / исключения во все правила, в которых вы хотите фильтровать те же файлы ... Я подумал, что было бы неразумно усложнять пример, но я имел в виду что-то вроде этого:

{
    "constants": {
        "generatedFilesGlob": "**/generated.ts",
        "someOtherConstant": "some other value, that could be reused",
        ...
    },
    "rules": {
        "class-name": true,
        "some-otherrule": [ true, "arg1", "arg2", "arg3"],
        "rule-with-exclude": [ {"exclude": "generatedFilesGlob"}, "arg1", "arg2", "arg3"],
        ...
    }
}

но это затруднит анализ файла конфигурации. Это заставило меня задуматься о поддержке файлов js для конфигурации в дополнение к файлам json. Например:

const generatedFilesGlob = "**/generated.ts";
const allExceptGenerated = {exclude: generatedFilesGlob};
module.exports = {
    "rules": {
        "class-name": true,
        "some-otherrule": [ true, "arg1", "arg2", "arg3"],
        "rule-with-exclude": [ allExceptGenerated , "arg1", "arg2", "arg3"],
        "another-rule-with-the-same-exclude-pattern": [ allExceptGenerated , "arg1", "arg2", "arg3"],
        ...
    }
}

Использование файлов JavaScript с модулями (например, gulp) имеет еще одно преимущество - они позволяют комментировать и не так строго относятся к запятым после последнего элемента в массиве или свойства в объекте.

@ atsu85 интересная проблема, но, как указал @myitcv, я не хочу вводить списки файлов / глобусы в tslint.json из-за дополнительной сложности / беспорядка в файле конфигурации. Я согласен с тем, что TSLint должен принимать файлы .js для настройки в дополнение к простым файлам .json . Я думаю, это поможет вам решить этот вариант использования - вы можете настроить две задачи сборки tslint (одну для ваших обычных источников, одну для сгенерированных источников) и программно отключить правило class-name в одной из них в том же файле tslintConfig.js .

Файл № 1065 для поддержки файлов конфигурации .js

Честно говоря, я закрываю эту проблему в пользу только файлов конфигурации js.

У меня есть вариант использования, который может иметь смысл. У меня есть тестовые файлы (* .spec.ts), с которыми я хочу поделиться большей частью моих правил Typescript TSLint, так как хорошие методы кодирования применимы и к моим тестам.

Однако я тестирую некоторые константы, настроенные для правила «магических чисел», чтобы в моем коде не было 5:
(Foo.substr(0,5);
но убедитесь, что это константа
(Foo.substr(0,CONSTANT.FIVE);

Таким образом, мой тестовый пример для моей константы, включенной из общего файла, имеет тест, гарантирующий, что const FIVE = 5 всегда установлена. Затем тест expect(CONSTANTS.FIVE).toBe(5); не проходит проверку TSLint, поскольку в тесте используется магическое число. Хотя я не тестирую все константы таким образом, я все же хочу проверить эти числовые параметры, чтобы убедиться, что они не меняются, поскольку ожидается, что они сохранят определенный размер.

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

Я могу сделать / * tslint: disable : no-magic-numbers * / для одного файла для этих конкретных тестов, который действительно работает для меня, но, возможно, в некоторых других случаях в файле тестов общее правило может быть исключением, и вместо обновления каждого * .spec.ts будет работать глобальный шаблон для правила?

У меня такой же вариант использования, как у @Chowarmaan.

У меня есть тестовые файлы *.test.ts в которых я использую зависимости разработчика, например enzyme .
В tslint.json у меня включено правило no-implicit-dependencies и я хочу отключить это правило только для *.test.ts . Не все эти тестовые файлы находятся в одной папке, поэтому сейчас я должен поместить:

/* tslint:disable:no-implicit-dependencies */

в начале каждого тестового файла, который раздражает

Это аналогичная проблема, с которой я столкнулся, а также с @RomanGotsiy, где вы можете добавить отключение в верхней части тестовых файлов, но это становится громоздким для каждого файла. Файлы исключения были бы полезны, поскольку вы могли бы исключить правила для определенных файлов шаблонов (тестовые файлы, * .spec.ts) и иметь один чистый файл конфигурации, который также позволяет вам просто включать больше правил по мере необходимости и разрешать ваши тесты также использовать их. Может быть, тогда список исключаемых файлов будет просто включать правила, которые вы хотите отключить, вместо того, чтобы добавлять исключения файлов к каждому правилу?

Этот. 100%. Возникла эта проблема с монорепозиторием, где тестовые зависимости перечислены в рабочей области, поэтому tslint плачет о no-implicit-dependencies . Это нужно сделать с помощью одного файла конфигурации, чтобы линтинг IDE продолжал работать.

Думаю, эта проблема тоже связана с # 3447

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

export const reducer = ( state = initialState, action: CurrentAction): CurrentState => {...}

Выдает ошибку Function expressions are not supported in decorators in 'reducers' . Проблема возникает из-за наших правил линтинга. Мы специально включили правило only-arrow-functions для всего проекта ... было бы замечательно добавить сопоставление с образцом в исключении, чтобы сказать исключить файлы *.reducer.ts в качестве примера для этого конкретного правила, но разрешить он останется неизменным для всех остальных файлов.

Как бы то ни было, добавление этой строки в начало файла для каждого файла-редуктора обременительно. Просто кажется, что должен быть способ получше.

Некробампинг и это тоже. Я пытаюсь добавить tslint-microsoft-contrib в проект Vue и кучу его правил для файлов .vue; это может быть полезным обходным путем для подобных проблем, прежде чем авторы правил приступят к устранению этих ошибок - если они когда-нибудь захотят. В настоящее время добавление комментария для отключения кучи правил абсолютно в каждый файл Vue, который я пишу, действительно громоздко. Также имеет смысл быть немного менее строгим в коде пользовательского интерфейса или иметь дело с идиомами фреймворка, например, использование экспорта по умолчанию.