Ответ 1

Ember-cli не поддерживает множество приложений из коробки. (Кстати, я все еще удивляюсь, сколько вещей, которые были распространены в SproutCore, все еще проблематичны с Ember). pods, о которых вы упомянули, поддерживаются инструментами, на которые зависит ember-cli, поэтому большинство команд ember-cli будут работать нормально. Способ распознавания (зависимость ember-cli) объединяет все, что описано в его запрос на удаление. Но вы не сможете использовать генераторы, потому что они еще не знают о контейнерах. Ember addons в основном расширяют ember-cli или Ember, хотя они могут решить вашу проблему, они не являются правильным инструментом.

Думаю, вам лучше подождать, пока еще больше команд ember-cli, которые будут знать об этом, или реализовать эту функцию для ember-cli.

Следующее лучшее - разделить проект на несколько проектов, по одному на приложение, и включить общий код через Bower, NPM или другое решение. Все они обычно позволяют импортировать зависимости через git или файловую систему, если у вас есть собственные частные компоненты. У вас может быть суперпроект, в котором все идет вместе (через NPM или Git подмодули) и где у вас все еще есть какое-то домашнее решение для оркестровки всего ( в основном делегируя его ember-cli).

Ответ 2

Если вы должны выполнить несколько приложений с помощью Ember CLI, за каждое редактирование 2015/1/28, вам нужно будет ждать поддержки большего количества поддержки или движков.

Рассмотрим, однако, наивное решение DIY здесь: сделайте свои n отдельные приложения Ember в n отдельных приложениях Ember CLI. Подайте их себе в одном суперпроекте .

Недостатки

Как и при расследовании аддонов, у вас будет повторяющийся шаблон, package.json, environment.js и т.д. Вы понесете накладные расходы на поддержание каждого приложения Ember, Ember CLI и т.д. версий отдельно. Вам нужно будет создать способ самостоятельно обслуживать их всех в суперпроекте. Даже если несколько приложений находятся в одной и той же версии библиотеки, клиентам, вероятно, придется загружать дублированный код vendor.js.

Это серьезные недостатки, которые вам придется взвесить.

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

• Вы сохраняете свою существующую организацию кода.

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

  "Дублирование намного дешевле, чем неправильная абстракция". В мире динамического JavaScript, где что-то идет в системе типов, и у всех есть другая реализация модуля, абстрагирование/извлечение слишком рано вызывает у вас проблемы. Когда общий код тщательно извлекается в отдельную библиотеку, возможно, используя правило 3 - это приводит к более качественному микролибу. Обслуживание lib может быть сосредоточено на оптимизации только общих функций и обратной совместимости. Возможно, вы не получите этого, если общий код останется в вашем приложении, используемом с помощью спагетти импорта.

  Как и с frzng answer, "включить общий код через Bower, NPM" и Ember addons.

• Технический долг одного приложения не испортил другое приложение.

  Это хорошо, особенно в экосистеме Ember. Несмотря на то, что его девиз - "стабильность без стагнации", новые шаблоны Ember выходят каждый день. Хотите попробовать один из тех, кто использует технологию Ember, но не хотите тратить время на модернизацию своего монолитного Ember? Обновите только одно меньшее приложение!

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

  (Прекращение распространения технического долга является частью того, почему микросервисы настолько популярны в последнее время. Многие небольшие приложения Ember можно назвать подходом к микросервисам.)

Суперпроект

Организация

Вы можете исследовать подмодули Git (* shudder *) поддеревья или артефакты NPM. Вы перейдете через обручи, чтобы синхронизировать их.

В моей ситуации нет смысла запускать 1 приложение без других. У меня был успех с monorepo.

Обслуживание

Моя схема URL-адресов работала для философии Unix, как разделение моих приложений Ember. Каждый из них может обслуживаться одним сервером, но каждый из них группируется по логически раздельному пути. Например, все запросы /app1/* передаются в приложение # 1, скомпилированное index.html. Все запросы /app2/* передаются в приложение # 2, скомпилированное index.html. И так далее. Ember берет на себя маршрутизацию оттуда.

Возможно, вы сможете сделать то же самое с /index/*, /admin/* и /reports/*.

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

for packageJson in packageJsons:
    path = packageJson.contextPath                               # e.g. '/app1/*'
    indexHtml = packageJson.abspath.dirname + '/dist/index.html' # Ember CLI conventional location

    # Dynamically mount the route.
    # Normally you'd hardcode your routes, something like  
    #     yourWebFramework.GET('/hello', echo('Hello world'))
    yourWebFramework.GET(path + '/*', serveStaticFile(indexHtml))