Как развернуть существующий пакет метеоритов чистым способом?

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

Насколько я могу судить, существуют следующие варианты. К сожалению, все они имеют свои проблемы, и я еще не нашел идеального решения. Я буду использовать meteor-router в качестве примера:

1. Просто скопируйте файлы пакета в папку с пакетами

Шаги:

  • удалить packages/router/.git/
  • отредактируйте packages/.gitignore и удалите строку 'router'
  • удалите маршрутизатор из smart.json
  • добавить packages/router в репозиторий проекта и зафиксировать
  • теперь вносите изменения (таким образом, ваша первоначальная фиксация является чистой версией, и вы можете решить, что вы изменили сами).

Преимущества:

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

Недостатки:

  • вы потеряете всю историю исходных репозиториев
  • сложно обновить до более новой версии
  • сложно внести изменения в исходный проект

Даже не рассматривайте это для каких-либо простейших пакетов!

2. Вилка на github, затем...

Чтобы разбить пакет на github, вы можете проверить свой файл smart.lock, чтобы узнать, какой репозиторий используется. Перейдите на страницу github этого репозитория и разблокируйте его.

Затем у вас есть три варианта:

2a. Добавьте его как подмодуль git

Дополнительная информация о подмодулях git: http://git-scm.com/book/en/Git-Tools-Submodules

Шаги:

  • См. ссылку выше о том, как запустить/создать/обновить подмодуль
  • Удалите пакет из smart.json

Преимущества:

  • версии субмодуля подключены к вашему проекту
  • Изменения сразу же подбираются

Недостатки:

  • Все разработчики должны запускать git submodule init в первый раз и update для обновления
  • Вы должны знать о проблемах с подмодулями при редактировании выписки
  • Читайте о других проблемах с подмодулями

2b. Измените проект smart.json, чтобы использовать свою версию

Шаги:

  • В smart.json найдите "router": {} и добавьте "git": "https://github.com/USER/meteor-router.git" в пустой {}.
  • При необходимости добавьте "branch" или "tag".

Преимущества:

  • Вы можете использовать Meteorite для управления внешними пакетами.
  • Будет работать автоматически для других разработчиков и в средах развертывания.

Недостатки:

  • Код в папке ваших пакетов не редактируется, так как это не репозиторий git
  • Meteorite не будет автоматически обновляться до последней версии при каждом запуске

(Предлагаемое улучшение метеорита: разрешить установку пакетов в редактируемой форме, например, Python pip позволяет использовать параметр -e)

2с. Clone вне вашего проекта и добавьте "path" в smart.json

Шаги:

  • Клонирование пакета к месту вне вашего проекта
  • Как и в случае с 2b, добавьте "path" к вашему smart.json, чтобы указать Meteorite на местную проверку

Преимущества:

  • Вы можете отредактировать пакет по своему усмотрению, и Meteor автоматически выполнит изменения.

Недостатки:

  • Если вы зафиксируете этот smart.json, вы, скорее всего, сломаете все другие среды разработки/развертывания...

Какой метод вы используете? Как вы преодолеваете недостатки этого метода?

Возможно, я пропустил некоторые проблемы с этими решениями.

Ответы

Ответ 1

2b. Отредактируйте свой проект smart.json, чтобы использовать свою версию

Я бы рекомендовал эту версию, поскольку она наиболее соответствует тому, как должен был использоваться и поддерживаться smart.json. mrt update будет правильно отражать последнюю из git repo, я думаю.

Ответ 2

Для Meteor 1.0 я рекомендую следующее:

  • Настройка локальной папки пакетов

    $ mkdir "$HOME/code/packages"

  • Добавьте переменную среды PACKAGE_DIRS в файл .bashrc/.zshrc

    export PACKAGE_DIRS="$HOME/code/packages"

  • Вилка и клонирование хранилища

    $ cd "$HOME/code/packages"
$ git clone <yourGithubFork>

  • Установите пакет из вашей файловой системы

    $ meteor add <packagenamespace>:<packagename>

Ответ 3

Есть еще более простой ответ, чем все вышеперечисленное. Создайте в своем проекте каталог, называемый пакетами, и поставьте пакет, который вы хотите переопределить. Простой!

Пример: предположим, что вы хотели внести некоторые изменения в accounts-ui-unstyled (что является субзависимостью of accounts-ui) от метеора. Сделайте git клон всего источника метеоров в локальном репозитории:

MyMachine:~ theuser$ cd Development/
MyMachine:Development theuser$ git clone https://github.com/meteor/meteor.git
MyMachine:Development theuser$ cp accounts-ui-unstyled ~/Development/MyProject/packages

В вашей структуре проекта у вас будет этот

MyProject
 |
 -> client
 -> lib
 -> packages
    |
    -> accounts-ui-unstyled
 -> private
 -> public
 -> server
 -> tests

Любые изменения, внесенные в MyProject/packages/accounts-ui-unpyled, теперь переопределяют пакет.

Ответ 4

Я использую гибрид опций # 2: я указываю smart.json при локальной проверке, но я помещаю все пакеты, включая приложение и извлеченные интеллектуальные пакеты, в качестве подмодулей git в родительский проект. Метеорит по-прежнему устанавливает остальные смарт-пакеты в приложении. Таким образом, когда вы разрабатываете смарт-пакеты, все остается неизменным, и вы можете перемещать свое приложение в обычный метеорит, когда ваша вилка объединяется.

Для примера см. https://github.com/mizzao/CrisisMapping. В моем случае, это даже не вилки, они просто умные пакеты, которые я разрабатываю за пределами последнего релиза метеорита.