Уходят ли зависимости служебной программы в devDependencies? - PullRequest
Новая
       38

Уходят ли зависимости служебной программы в devDependencies?

0 голосов
/ 11 ноября 2018

Я пишу библиотеку в NodeJS, которая будет использоваться другими. В этой библиотеке есть тесты, которые зависят от среды тестирования, поэтому эта структура указана в разделе devDependencies в package.json, поэтому любой, кто вставит мою библиотеку в свой код, не загрузит мою среду тестирования, а затем проигнорирует.

Однако у меня также есть интерфейс командной строки к библиотеке, который должен быть установлен, если кто-то решит установить библиотеку в глобальном масштабе, но также должен игнорироваться, когда кто-то другой тянет библиотеку в свой собственный проект. Этот CLI имеет некоторые зависимости, поэтому я пытаюсь выяснить, где их перечислить, чтобы они использовались при глобальной установке (или во время разработки самой библиотеки), но игнорируются, когда другой проект добавляет библиотеку в качестве своей зависимости.

  • Если я перечислю зависимости CLI в главном разделе dependencies, то пользователи библиотеки получат их все в свой собственный код, даже если они никогда не будут использовать CLI, так что это определенно неправильно место.

  • Если я перечислю их как devDependencies, тогда они будут исключены из других проектов, что идеально, однако, если кто-то попытается установить библиотеку глобально с помощью --production, то зависимости CLI будут опущены, а CLI не будет работать, даже если в этом случае «производственная» установка обязательно должна включать CLI.

  • bundledDependencies не похоже на то, что мне нужно, поскольку я не хочу включать зависимости CLI в какие-либо пакеты, так как это, скорее всего, те случаи, когда CLI не будет использоваться .

  • peerDependencies в данном случае не имеет значения.

  • optionalDependencies не кажется идеальным, потому что, если по какой-либо причине не получается зависимость CLI, глобальная установка будет продолжена, но CLI не будет работать, что является своего рода точкой глобальной установки.

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

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

1 Ответ

0 голосов
/ 12 ноября 2018

Я думаю, что лучший подход - это иметь CLI в отдельном пакете, похожем на express-generator , который является CLI для express.

Даже если это важно для разработки, пользователям вашей библиотеки нужно будет набрать только одну дополнительную команду, npm install library-cli, и если это правильно задокументировано, я не вижу никаких проблем.

Вы также можете добавить сценарий postinstall или пользовательский сценарий в основную библиотеку, которая устанавливает CLI после установки пакета: 

"scripts": {
    "postinstall": "npm install -g library-cli"
}

Однако также хорошо, если вы решили связать свой CLI с основной библиотекой, однако в этом случае вам не следует помещать зависимости CLI в devDependencies. Все модули, необходимые для запуска cli, должны входить в dependencies, даже если 90% пользователей никогда не будут их использовать.

devDependencies следует использовать для всех инструментов, которые требуются в процессе сборки, таких как минификация, тесты, машинопись и т. Д. Все, что требуется во время выполнения для вашего CLI , должно входить в dependencies .

...