Как мне решить, входит ли @ types / * в «зависимости» или «devDependencies»?

200

Я использую TypeScript 2 в моем проекте. Я хотел бы использовать библиотеку js, но также набирать тексты для этой библиотеки. Я могу установить типы с простым npm install @types/some-library. Я не уверен, должен ли я --saveили --save-devони. Мне кажется, что даже в ReadmeTyped GitHub readme упоминает обе версии, но никогда не объясняет их. Я думаю, что @types должен присутствовать devDependencies, так как типы необходимы для разработки и не используются во время выполнения, но я много раз видел @types просто dependencies. Я запутался.

Как мне решить, входит ли @ types / * в dependenciesили devDependencies? Есть ли какие-то более или менее официальные инструкции?

— kamyl
источник

Вы генерируете пакет или этот пакет будет использоваться другими? На мой взгляд, вам нужно только провести различие между dependenciesи devDependenciesв последнем случае.

— Валентин

Я делаю некоторые игры в JS / TS с нуля. Я связываю все с веб-пакетом. Там вообще нет никакого механизма, но возможно, что я заверну все это в Electron, чтобы когда-нибудь сделать его автономным. Я не думаю, что кто-то когда-либо будет использовать его в качестве зависимости в своем собственном приложении, но думаю, что это возможно (подумайте о мини-играх в играх GTA; моя игра с открытым исходным кодом). Тем не менее, я хочу изучать лучшие практики и следовать им, и это главная причина, по которой я создаю эту игру. Надеюсь, я достаточно хорошо прояснил свой вариант использования. :)

— kamyl

Да, это имеет смысл, просто хотел убедиться, что мой оригинальный ответ был актуален для вашего варианта использования. Я до сих пор думаю , что различие между devDependenciesи dependenciesне имеет никакого значения при построении сверток, это то , что create-react-appнавязывает , как хорошо , но в конечном счете , это до вас , чтобы выбрать

— Valentin

Ответы:

140

Допустим, вы разрабатываете пакет «A», в котором есть пакет @ types / some-module в devDependencies. По какой-то причине вы экспортируете тип из @ types / some-module

import {SomeType} from 'some-module';
export default class APackageClass {
     constructor(private config: SomeType) {

     }
}

В настоящее время потребители Typescript пакета "A" не могут угадать, что такое SomeType, поскольку devDependencies пакета "A" НЕ установлены.

В этом конкретном случае вам необходимо разместить пакет @ types / * с обычными «зависимостями». Для других случаев «devDependencies» достаточно хороши.

— wookieb
источник

Таким образом, вы подразумеваете, что, если я использую только тип в реализации, это определение типа может быть devDependencies?

— Франклин Ю

Да, @FranklinYu. Как только тип появится в файле декларации, вы должны поместить его в dependencies. В противном случае devDependenciesвсе в порядке

— вуки

Но пакет работает как для TS, так и для JS. Разработчикам JS эти типы не нужны для компиляции их кода. Добавление определения типа к dependenciesсделает дерево зависимостей раздутым.

— Тайлер Лонг

@TylerLong Правильно. Это не идеально, но это реальность. При желании вы также можете использовать «AdditionalDependencies», но я считаю, что в масштабе это может быть очень раздражающим.

— вуки

Если вы просто генерируете пакет, вам может не понадобиться делать различие между dependenciesи devDependencies. Эта функция npmобычно полезна при публикации пакета, который может использоваться другими, и вы не хотите рассылать им спам с избыточными зависимостями.

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

Хорошо известным примером этой практики IRL является то create-react-app, что по умолчанию неотбрасываемый шаблон создает все dependencies, смотрите эту ветку и этот ответ.

— Valentin
источник

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

— Йогу

@Yogu Вот почему я сделал различие в первую очередь, так что да, я полностью согласен с тобой

— Валентин

Я не согласен с этим советом. devDependenciesне устанавливаются, когда вы делаете npm install --production(или npm ci --production), и, следовательно, недоступны при запуске производственного кода. Это очень значимое различие для службы, а не только для библиотеки.

— Брэд Уилсон

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

— Валентин

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

— Валентин

В конкретном случае развертывания приложения Node.js в рабочей среде требуется установить только те зависимости, которые необходимы для запуска приложения.

npm install --production или

npm ci --production или

yarn --production

В этом случае типы должны быть devDependencies, чтобы они не вздулись при установке.

Замечание: я знаю, что это было упомянуто в комментарии Брэда Уилсона к другому ответу. Этот момент кажется достойным ответа, хотя.

— Карстен Фюрманн
источник