Вместо такого импорта:
Я хочу иметь что-то похожее на:
Для этого мы внесем небольшое изменение в файл 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 (с использованием схемы)
Удачного ангуляринга!