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

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

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

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

Однако рассмотрите здесь наивное решение «сделай сам»: превратите свои n отдельные приложения Ember в n отдельные приложения Ember CLI. Сами обслужите их в рамках единственного суперпроекта.

Недостатки

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

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

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

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

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

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

   Как и в случае с ответом frzng, включите общий код через надстройки Bower, NPM и Ember.

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

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

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

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

Суперпроект

Организация

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

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

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

Моя схема URL-адресов работала для разделения моих приложений Ember, аналогичного философии Unix. Каждый из них может обслуживаться одним сервером, но каждый из них сгруппирован по логически отдельному контекстному пути. Например, все запросы к /app1/* направляются в скомпилированный файл index.html приложения №1. Все запросы к /app2/* направляются в скомпилированный файл index.html приложения №2. И так далее. Оттуда 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's 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))