Вместо такого импорта:

Я хочу иметь что-то похожее на:

Для этого мы внесем небольшое изменение в файл tsconfig.json. Мы добавим следующие строки в коллекцию путей:

Приведенная выше модификация создает некоторые сокращения для папок. И с этого момента мы можем ссылаться на элементы внутри этих папок, например:

2) Создайте новый файл TypeScript, в котором мы напишем пользовательское правило TSLint:

Наше пользовательское правило будет реализовывать поведение: импорт из функциональных модулей запрещен. Итак, следуя соглашениям об именах в документации TSLint, мы получим файл: noImportFromFeatureModulesRule.ts. Я создал файл в новой папке в корне проекта с именем P18TSLintRules (это имя папки не обязательно, вы можете использовать свое).

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

Первый класс будет называться Rule (в соответствии с соглашением) и будет расширять Lint.Rules.AbstractRule.

Здесь у нас есть код класса (только соответствующая часть):

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

Механизм TSLint будет считывать метаданные при выполнении проверок. Эти метаданные также определяют текст некоторых подсказок, отображаемых в среде IDE. Два соответствующих свойства метаданных:

TypescriptOnly: Настройте, может ли механизм TSLint также использовать это правило для файлов с чистым javascript.

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

Мы можем передать некоторые параметры конфигурации нашему пользовательскому правилу. Эти конфигурации считываются в коллекцию параметров. Файл tsconfig.json хранит конфигурацию. Позже мы рассмотрим эту конфигурацию более подробно.

Последняя важная роль, которую играет этот класс, — внедрить наш второй класс в исполнительный механизм TSLint с именем Walker.

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

Имя класса — NoImportFromFeatureModulesWalker, и здесь мы собираемся выполнить проверки, чтобы проверить, соответствует ли импорт в конкретном файле политике, которую мы хотим применить. Класс расширяет Lint.RuleWalker.

Это работает следующим образом: инфраструктура TSLint будет проходить по всем узлам AST (абстрактного синтаксического дерева) для каждого файла машинописного текста в приложении. Для каждого узла он будет вызывать соответствующие методы из нашего класса для проверки каждого типа узла. Затем мы просто переопределяем методы, вызываемые для типов узлов, которые мы хотим проанализировать.

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

3) Настройте нашу среду, чтобы в процессе проверки применялось новое пользовательское правило:

Процесс настройки прост. Нам просто нужно сообщить инфраструктуре TSLint, что новое пользовательское правило активно и где оно находится. В моем случае я отредактирую файл tslint.json, чтобы добавить папку P18TSLintRules в коллекцию rulesDirectory, а также добавить строку «no-import-from-feature-modules»: [true», «featureModules»] в сборник правил.

И это все! Конфигурация готова. Вот как сейчас выглядит tslint.json:

Теперь все настроено для идентификации и разрешения TSLint использовать наше правило. Однако нам нужно сделать еще один шаг, прежде чем мы сможем использовать наше правило: нам нужно скомпилировать файл .ts, содержащий код правила. Чтобы скомпилировать все файлы машинописного текста, находящиеся в папке, вы можете перейти в папку и запустить:

tsc *.ts

Это будет работать, если вы используете bash, но появится сообщение об ошибке, например «ошибка TS2304: не удается найти имя «Карта»». Чтобы создать более универсальное и красивое решение, мы выполним еще несколько шагов:

1) Перейдите в папку, в которой вы создали правила, и выполните следующую команду:

tsc init

это создаст файл конфигурации машинописного текста по умолчанию, tsconfig.json.

2) Отредактируйте только что созданный tsconfig.json:

Откройте файл, замените строку, содержащую ‘// “lib”:[]’ на ‘“lib”: [“es6”]’ (без кавычек). Это позволит компилятору использовать библиотеки es6 (EcmaScript 6), а также позволит избежать ошибки, которую мы видели при запуске tsc *.ts.

Сохраните файл и выполните следующую команду:

tsc -p tsconfig.json

Теперь вы должны увидеть скомпилированный файл без сообщения об ошибке.

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

3) Отредактируйте файл package.json

В этот файл мы добавим следующую строку:

в коллекцию скриптов. Сохраните файл.

Теперь мы можем выполнить

npm run tscrules

в любую папку с помощью любой оболочки и правила всегда будут корректно составлены.

И это все.

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

И если вы нашли этот контент полезным, вы можете найти больше в этих других статьях:

https://goo.gl/k6LPoU (используя Web Speech API с Angular)

https://goo.gl/Yh7HVn (с использованием схемы)

Удачного ангуляринга!