Как сделать, чтобы npm установил зависимости в пользовательском расположении и избежал переноса в node_modules? - PullRequest
Новая
       8

Как сделать, чтобы npm установил зависимости в пользовательском расположении и избежал переноса в node_modules?

0 голосов
/ 05 декабря 2018

Я опубликовал пакет parent-package, у которого есть зависимость, - это другой пакет с именем child-package, который уже опубликован на npm.Когда я устанавливаю parent-package, он оборачивается в node_modules, а его зависимости также оборачиваются в node_modules на том же уровне, что и parent-package.Я не хочу, чтобы parent_package был обернут в node_modules, а child-package должен храниться в папке проектов, потому что в моем случае child-package - это независимая библиотека, которая будет использоваться в parent-package.Согласно поведению по умолчанию, моя структура папок выглядит следующим образом:

Present Working Director: |-- node_modules |-- parent-package |-- child-package |-- other dependencies

Я хочу получить эту структуру папок при установке по умолчанию;

Present Working Director: |-- parent-package |-- projects |-- child-package |-- other libraries |-- src

Как изменить поведение по умолчанию при установке npm для достижения этой структуры?Любая помощь будет оценена.

1 Ответ

0 голосов
/ 05 декабря 2018

Вы можете пойти двумя, тремя (или более) способами: npm и Angular.

npm

Одним из способов является использование сценария postinstall дляnpm - выполняется, как вы подозреваете, после установки пакета.Вот наивный пример.

Добавьте это к package.json: 

"scripts": {
  ...
  "postinstall": "./postinstall.sh"
}

и создайте скрипт postinstall.sh bash: 

#!/bin/sh
cp -r node_modules/parent_project .
cp -r node_modules/child_package ./parent_project
...other things to copy.

Это создаст структурувы хотите.

Обратите внимание, что с этим есть несколько проблем.Можно было бы сказать, что это не совсем кроссплатформенность.Другая проблема заключается в том, что он не будет работать на некоторых старых версиях npm (которые вкладывают зависимости во вложенные модули node_modules).Наконец, я бы очень настороженно относился к пакету, который копирует сценарии непосредственно в мои исходные папки, возможно, перезаписывая вещи, если это не было явно указано и сказано.

Все эти проблемы могут быть решены, но требуют некоторого обдумывания.

Угловой путь

Угловой путь - это на самом деле несколько из них.Самый простой способ - создать угловую схему и опубликовать ее вместо библиотеки напрямую.

Когда я использую библиотеку npm, я ожидаю, что она будет в node_modules, а не вв моих источниках.Я не хочу этого в моих источниках, просто вещи, которые я на самом деле экспортирую.Например, @angular/core сам находится в node_modules, и это не мешает мне.

Schematics

Но когда я do хочу, чтобы эта библиотека как-то мне помоглаЯ хочу, чтобы это было явно - вызывая команду.И Angular Schematics дает вам это.

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

Monorepo

Другой возможный способ, если вы разрабатываете пакет для себя, это использовать Monorepoстратегии и, скажем, ng-packager для работы с вашими «дочерними пакетами» и библиотеками.

Другие генераторы

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

Редактировать: Вы упоминаете в комментариях, которые вы хотите перейти "способ npm ", но вы имеете в виду случай использования, когда вам кажется, что вам нужна библиотека npm и редактируемый пакет в одном.Так почему бы не относиться к этому так?Ясно, что это не просто «путь npm», потому что изменение исходников - это не то, для чего нужен механизм установки / обновления npm - он предназначен для управления зависимостями.

Самый простой способ использовать оба способа (каламбур)использовать механизм установки / обновления npm для управления сценарием использования «use as library» и обычным git для сценария использования «use as source».

Сделайте ваш родительский проект обычным угловым проектом (new new parent),Затем в рамках этого проекта также создайте библиотеку (ng generate library child).

Наконец, у вас есть ссылка в tsconfig путях к dist/library/, поэтому вы используете только «скомпилированные» версии библиотеки вВаш родительский проект.

Теперь настройте ваши сценарии npm следующим образом: 

"build.parent": "regular parent build stuff"
"build.child": "build the child library"
"publish.parent": "stuff to publish the parent to npm"
"publish.lib": "ng-packagr stuff to publish the library to npm"

Итак, варианты использования:

  1. Вы хотите использовать их простокак библиотеки npm.Супер просто и прямо.

    npm установить дочерний пакет родительского пакета --save-dev

  2. Вы хотите иметь локальный материал:

    git clone github.com/you/repo.git

Теперь вы можете использовать локальную версию и версию библиотеки.А если серьезно, не надо.Если это библиотека, это библиотека.В противном случае, не управляйте этим с помощью npm, когда git буквально создан для этого, управления версиями.

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

Тем не менее, если вы действительно должны сделать это, то сценарии после установки должны это сделать.Но эти сценарии действительно должны быть продвинутыми, достаточно умными, чтобы обнаружить, что вы обновили проекты, имеете разумные стратегии слияния, миграции и т. Д. И в итоге вы на самом деле пишете Angular Schematic, но не с Angular.

...