{"_id":"@buschtoens/ember-engines","_rev":"3-ff0d86c683415447f9a960787849c822","name":"@buschtoens/ember-engines","dist-tags":{"beta":"0.5.26-beta.2","latest":"0.5.26-beta.1","rc":"0.7.2-rc.1"},"versions":{"0.5.26-beta.1":{"name":"@buschtoens/ember-engines","version":"0.5.26-beta.1","description":"Experimental support for Ember Engines","directories":{"doc":"doc","test":"tests"},"scripts":{"build":"ember build","lint:js":"eslint ./*.js addon addon-test-support app config lib tests","start":"ember serve","test":"ember test","test:all":"ember try:each","test:ember":"ember try:one $EMBER_TRY_SCENARIO test --skip-cleanup","test:emberall":"ember try:each --skip-cleanup","test:lint":"eslint index.js addon addon-test-support app bin config lib node-tests tests vendor","test:lint:fix":"eslint --fix index.js addon addon-test-support app bin config lib node-tests tests vendor","test:node":"mocha 'node-tests/**/*-test.js' --reporter tap","test:windows":"ember try:one %EMBER_TRY_SCENARIO% test --skip-cleanup","test:node:dev":"BUILD_DEV=true testem -f testem-node.js","test:null":"echo 'no appropriate changes detected, not running tests'"},"repository":{"type":"git","url":"git+https://github.com/ember-engines/ember-engines.git"},"authors":["Dan Gebhardt","Robert Jackson"],"license":"MIT","devDependencies":{"broccoli-asset-rev":"^2.7.0","chai":"^4.1.2","common-tags":"^1.8.0","eager-blog":"link:./tests/dummy/lib/eager-blog","ember-ajax":"^3.1.0","ember-blog":"link:./tests/dummy/lib/ember-blog","ember-chat":"link:./tests/dummy/lib/ember-chat","ember-cli":"~3.3.0","ember-cli-addon-tests":"^0.11.0","ember-cli-app-version":"^3.2.0","ember-cli-dependency-checker":"^3.0.0","ember-cli-htmlbars":"^3.0.0","ember-cli-htmlbars-inline-precompile":"^1.0.3","ember-cli-inject-live-reload":"^1.4.1","ember-cli-qunit":"^4.3.2","ember-cli-shims":"^1.2.0","ember-cli-sri":"^2.1.0","ember-cli-uglify":"^2.1.0","ember-disable-prototype-extensions":"^1.1.2","ember-export-application-global":"^2.0.0","ember-load-initializers":"^1.1.0","ember-resolver":"^5.0.1","ember-sinon":"^2.1.0","ember-source":"~3.3.0","ember-source-channel-url":"^1.1.0","eslint":"^5.1.0","eslint-config-prettier":"^2.9.0","eslint-plugin-ember":"^5.2.0","eslint-plugin-node":"^7.0.1","eslint-plugin-prettier":"^2.6.2","execa":"^0.10.0","fixturify":"^0.3.4","fs-extra":"^7.0.0","loader.js":"^4.7.0","mocha":"^5.2.0","prettier":"^1.13.7","walk-sync":"^0.3.1"},"keywords":["ember-addon"],"dependencies":{"amd-name-resolver":"1.2.0","babel-plugin-compact-reexports":"^1.0.0","broccoli-babel-transpiler":"^6.4.3","broccoli-concat":"^3.4.0","broccoli-debug":"^0.6.4","broccoli-dependency-funnel":"^2.1.0","broccoli-file-creator":"^2.1.1","broccoli-funnel":"^2.0.1","broccoli-merge-trees":"^3.0.0","broccoli-test-helper":"^1.3.0","calculate-cache-key-for-tree":"^1.0.0","ember-asset-loader":"^0.4.3","ember-cli-babel":"^6.12.0","ember-cli-preprocess-registry":"^3.1.2","ember-cli-string-utils":"^1.0.0","ember-cli-version-checker":"^2.1.2","ember-maybe-import-regenerator":"^0.1.6","ember-try":"^0.2.23","lodash":"^4.17.10"},"engines":{"node":"^4.5 || 6.* || >= 7.*"},"ember-addon":{"configPath":"tests/dummy/config"},"gitHead":"daf4b2cbb8f74cf459fd72ad8cd0133e3331bbe2","bugs":{"url":"https://github.com/ember-engines/ember-engines/issues"},"homepage":"https://github.com/ember-engines/ember-engines#readme","_id":"@buschtoens/ember-engines@0.5.26-beta.1","_npmVersion":"6.5.0","_nodeVersion":"11.6.0","_npmUser":{"name":"buschtoens","email":"buschtoens@gmail.com"},"dist":{"integrity":"sha512-eHl53JReXTDMY3au1Mie1Cd2wDxv8nZT/fIc4i3miNMbP+OhDRNoBcdJ5OuMqkzcOTxZS+1IF7t6vOFBFGExXw==","shasum":"59ca0a38d008d74d1a227d776428ddeb44e1170e","tarball":"https://registry.npmjs.org/@buschtoens/ember-engines/-/ember-engines-0.5.26-beta.1.tgz","fileCount":73,"unpackedSize":391391,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcNfv8CRA9TVsSAnZWagAASjUP/2ql7JOCB/w52VTyTD1p\nUTxMln2tBnWrZJb7fAfhT5nERt/wdCfaW+I1aGCHSogD7IzSCJi+82aaq8rp\nViM9yOjoHc3mnoNUyrhiiPPfdarvxIl7SWmc03DLqFpR5Of3DlwvoKSpNQ/w\nrQqX1s3U5OLId+q5QdueBE4X0le/R+kUdswErLetLh/xbv3O/fQUzHFQ29Rc\n0JLVUbTAK3VZBimEqBFbYZ2+HcYOYL2JEBsqaj9PPtusZjrQTu/RThNzNuyV\n3iLwady8b1hSDbL+CKvUAAo0pffOrZT2UzGxxsUHaJbmEu/Eis1audNVdsSs\nvfojob2+YTqfQoajOBM1Nzg8bZn8TLH17CE2EVOy15POQqzI8ZuojZBV2hLd\n0AH8CnjYNAWG3SSeEEz6wHvB/xiSO/U4xVm9xvxfVP2618U03XMb7nxH0hKa\nyjhXWFq/hbamwW/4y5Q7DbfK4vDZfLvV95DwPEZLZNkQdFN/ZTPqyclN+zjf\nx5t48YOafszYoaPTOpxhj3SPvHn1k4YVvYKyKdAepXfEOBuB3optydjDQKcC\nehU39J/wPfsB9PNaO4WTsJgOAyVdI5CgPpbMb2V1E7wjnOtr8Ho85HhT3UzC\nN69VyPmHaiwqoMdYUOhdLA/t9SUimXTpCHsGt1g5xEWPmCOw2uB9nrwrtyYV\ngCLM\r\n=RyIM\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDP2W+u8FIdI2GMHqm+C2pIdMkFKTcHOGSebwGwzXDd6AIhAOi3ZZF78fQga0rLu+pbGk2RbnzzNXRNz0EfJWmYCzeM"}]},"maintainers":[{"name":"buschtoens","email":"buschtoens@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/ember-engines_0.5.26-beta.1_1547041787833_0.13396620663830427"},"_hasShrinkwrap":false},"0.5.26-beta.2":{"name":"@buschtoens/ember-engines","version":"0.5.26-beta.2","description":"Experimental support for Ember Engines","directories":{"doc":"doc","test":"tests"},"scripts":{"postinstall":"node ./postinstall","build":"ember build","lint:js":"eslint ./*.js addon addon-test-support app config lib tests","start":"ember serve","test":"ember test","test:all":"ember try:each","test:ember":"ember try:one $EMBER_TRY_SCENARIO test --skip-cleanup","test:emberall":"ember try:each --skip-cleanup","test:lint":"eslint index.js addon addon-test-support app bin config lib node-tests tests vendor","test:lint:fix":"eslint --fix index.js addon addon-test-support app bin config lib node-tests tests vendor","test:node":"mocha 'node-tests/**/*-test.js' --reporter tap","test:windows":"ember try:one %EMBER_TRY_SCENARIO% test --skip-cleanup","test:node:dev":"BUILD_DEV=true testem -f testem-node.js","test:null":"echo 'no appropriate changes detected, not running tests'"},"repository":{"type":"git","url":"git+https://github.com/ember-engines/ember-engines.git"},"authors":["Dan Gebhardt","Robert Jackson"],"license":"MIT","devDependencies":{"broccoli-asset-rev":"^2.7.0","chai":"^4.1.2","common-tags":"^1.8.0","eager-blog":"link:./tests/dummy/lib/eager-blog","ember-ajax":"^3.1.0","ember-blog":"link:./tests/dummy/lib/ember-blog","ember-chat":"link:./tests/dummy/lib/ember-chat","ember-cli":"~3.3.0","ember-cli-addon-tests":"^0.11.0","ember-cli-app-version":"^3.2.0","ember-cli-dependency-checker":"^3.0.0","ember-cli-htmlbars":"^3.0.0","ember-cli-htmlbars-inline-precompile":"^1.0.3","ember-cli-inject-live-reload":"^1.4.1","ember-cli-qunit":"^4.3.2","ember-cli-shims":"^1.2.0","ember-cli-sri":"^2.1.0","ember-cli-uglify":"^2.1.0","ember-disable-prototype-extensions":"^1.1.2","ember-export-application-global":"^2.0.0","ember-load-initializers":"^1.1.0","ember-resolver":"^5.0.1","ember-sinon":"^2.1.0","ember-source":"~3.3.0","ember-source-channel-url":"^1.1.0","eslint":"^5.1.0","eslint-config-prettier":"^2.9.0","eslint-plugin-ember":"^5.2.0","eslint-plugin-node":"^7.0.1","eslint-plugin-prettier":"^2.6.2","execa":"^0.10.0","fixturify":"^0.3.4","fs-extra":"^7.0.0","loader.js":"^4.7.0","mocha":"^5.2.0","prettier":"^1.13.7","walk-sync":"^0.3.1"},"keywords":["ember-addon"],"dependencies":{"amd-name-resolver":"1.2.0","babel-plugin-compact-reexports":"^1.0.0","broccoli-babel-transpiler":"^6.4.3","broccoli-concat":"^3.4.0","broccoli-debug":"^0.6.4","broccoli-dependency-funnel":"^2.1.0","broccoli-file-creator":"^2.1.1","broccoli-funnel":"^2.0.1","broccoli-merge-trees":"^3.0.0","broccoli-test-helper":"^1.3.0","calculate-cache-key-for-tree":"^1.0.0","ember-asset-loader":"^0.4.3","ember-cli-babel":"^6.12.0","ember-cli-preprocess-registry":"^3.1.2","ember-cli-string-utils":"^1.0.0","ember-cli-version-checker":"^2.1.2","ember-maybe-import-regenerator":"^0.1.6","ember-try":"^0.2.23","lodash":"^4.17.10"},"engines":{"node":"^4.5 || 6.* || >= 7.*"},"ember-addon":{"configPath":"tests/dummy/config"},"readme":"# ember-engines [![npm version](https://badge.fury.io/js/ember-engines.svg)](https://badge.fury.io/js/ember-engines) [![Build Status](https://travis-ci.org/ember-engines/ember-engines.svg?branch=master)](https://travis-ci.org/ember-engines/ember-engines)\n\nThis Ember addon implements the functionality described in the [Ember Engines\nRFC](https://github.com/emberjs/rfcs/blob/master/text/0010-engines.md). Engines allow multiple logical\napplications to be composed together into a single application from the user's\nperspective.\n\nThis addon must be installed in any ember-cli projects that function as either\nconsumers or providers of engines. The following functionality is supported:\n\n* Routable engines which can be mounted at specific routes in a routing map, and\n  which can contain routes of their own.\n* Route-less engines, which can be rendered in a template using the `{{mount}}`\n  keyword.\n* Sharing of dependencies from parents (applications or other engines) to\n  contained engines. Shared dependencies are currently limited to services\n  and route paths.\n* Lazy loading of engines.\n\nThe following functionality will soon be supported:\n\n* Route serializer modules that isolate serialization logic from the rest of\n  the route definition.\n\nSupport for the following concepts is under consideration:\n\n* Namespaced access to engine resources from applications.\n* Sharing of dependencies other than services and route paths.\n* Passing configuration attributes from an engine's parent.\n\n## Important Note about Compatibility and Stability\n\nThis addon should be considered experimental. But engines are production ready and many of the APIs are fully stable.\n\nThe [master branch of this addon](https://github.com/ember-engines/ember-engines)\nis being developed against the master branch of Ember and Ember-CLI, and should\nbe considered unstable. If you're planning to deploy to production, please use\none of the stable releases.\n\n[v0.5.15 or higher](https://github.com/ember-engines/ember-engines/tree/v0.5.15)\nis compatible with FastBoot 1.0+.\n\n[v0.5 of this addon](https://github.com/ember-engines/ember-engines/tree/v0.5.0)\nis compatible with v2.12.x of both Ember and Ember-CLI.\n\n[v0.4 of this addon](https://github.com/ember-engines/ember-engines/tree/v0.4.0)\nis compatible with v2.10.x of both Ember and Ember-CLI.\n\n[v0.3 of this addon](https://github.com/ember-engines/ember-engines/tree/v0.3)\nis compatible with v2.8.x of Ember. This is the first version of Ember in which\nthe required hooks for engines are available without a feature flag.\n\n## Introduction Video\n\n[![Introduction to Ember Engines at Global Ember Meetup](https://i.vimeocdn.com/video/559400541_640x360.jpg)](https://vimeo.com/157688181)\n\n## Installation\n\nFrom your Ember CLI project's root directory, run the following:\n\n```\nember install ember-engines\n```\n\nInstall the appropriate version of Ember as noted above.\n\n## Providing Engines\n\n### Creating Engines\n\nEngines can be created as separate addon projects or in-repo addons.\n\nSeparate addon projects can be created with the `addon` command:\n\n```\nember addon <engine-name>\n```\n\n_Note: As described in the RFC, ember-cli will hopefully support an `engine`\ncommand to get started more easily with engine projects._\n\nIn order to create an engine within an existing application's project, run the\n`in-repo-engine` generator:\n\n```\nember g in-repo-engine <engine-name>\n```\n\nDon't forget to install `ember-engines` and the appropriate version of Ember in\nyour project, as described above.\n\n### Lazy Loading Engines\n\nYou must also declare in your Engine's `index.js` file whether or not the engine should be lazy loaded. Until lazy loading is supported, this should be set to `false`:\n```js\nconst EngineAddon = require('ember-engines/lib/engine-addon');\nmodule.exports = EngineAddon.extend({\n  name: 'ember-blog',\n  lazyLoading: {\n    enabled: false\n  }\n});\n```\n\n### Routable Engines\n\nRoutable engines should declare their route map in a `routes.js` file within your engine's `addon` directory.\nFor example:\n\n```js\nimport buildRoutes from 'ember-engines/routes';\n\nexport default buildRoutes(function() {\n  this.route('new');\n\n  this.route('post', { path: 'post/:id' }, function() {\n    this.route('comments', function() {\n      this.route('comment', { path: ':id' });\n    });\n  });\n});\n```\n\nRoutable engines interact with the parent application's router as if they are\nan extension of the parent application. A routable engine's application route\nwill be mounted wherever specified by the parent's route map (its \"mountpoint\").\n\n### Route-less Engines\n\nRoute-less engines should define an `engine.js` as described above. Neither\n`router.js` nor `routes.js` should be defined. Route-less engines will be rendered as their application template\n(`templates/application.hbs`).\n\n### Declaring Dependencies\n\nYour engine should declare any dependencies that it expects from its parent.\nDependencies must be declared in the engine definition.\n\nFor example, the following engine requires a `store` service from its parent:\n\n```js\nimport Engine from 'ember-engines/engine';\nimport Resolver from 'ember-resolver';\nimport loadInitializers from 'ember-load-initializers';\nimport config from './config/environment';\n\nconst { modulePrefix } = config;\n\nconst Eng = Engine.extend({\n  modulePrefix,\n  Resolver,\n  dependencies: {\n    services: [\n      'store'\n    ]\n  }\n});\n\nloadInitializers(Eng, modulePrefix);\n\nexport default Eng;\n```\n\nCurrently, only services and route paths (see below) can be shared across the\nparent/engine boundary.\n\n### Linking To External Routes\n\nLinking to routes outside of an Engine's isolated context is currently supported\nby defining \"external routes\" as dependencies of your Engine.\n\nYou specify **what** external things your Engine wants to link to by providing\nan array of names like so:\n\n```js\n// ember-blog/addon/engine.js\nexport default Engine.extend({\n  // ...\n  dependencies: {\n    externalRoutes: [\n      'home',\n      'settings'\n    ]\n  }\n});\n```\n\nThe Engine's consumer is then responsible for defining **where** those things are\nlocated via a route path:\n\n```js\n// dummy/app/app.js\nimport Application from '@ember/application';\nimport Resolver from './resolver';\nimport loadInitializers from 'ember-load-initializers';\nimport config from './config/environment';\n\nconst App = Application.extend({\n  modulePrefix: config.modulePrefix,\n  podModulePrefix: config.podModulePrefix,\n  Resolver,\n\n  engines: {\n    emberBlog: {\n      dependencies: {\n        externalRoutes: {\n          home: 'home.index',\n          settings: 'settings.blog.index'\n        }\n      }\n    }\n  }\n});\n```\n\nYou can then use those external routes either programmatically or within a\ntemplate like so:\n\n```hbs\n{{#link-to-external 'home'}}Go home{{/link-to-external}}\n```\n\n```js\n// ember-blog/addon/some-route.js\nthis.transitionToExternal('settings');\n```\n\nFor further documentation on this subject, view the [Engine Linking RFC](https://github.com/emberjs/rfcs/pull/122).\n\n### Lazy-Loading Routing Considerations\n\nWhen routing into an Engine that is lazily loaded there are some special considerations and subtle differences from how routing works in a normal Ember application.\n\n#### Serialization of URLs\n\nSince the links to your Engine are constructed before the Engine itself is loaded, you need to make sure the application has the necessary code to serialize data into the URLs. To that end, you need to replace any [`Route#serialize`](http://emberjs.com/api/classes/Ember.Route.html#method_serialize) functions with route serializers, as defined in [the Route Serializers RFC](https://github.com/emberjs/rfcs/blob/master/text/0120-route-serializers.md).\n\nFor example, if you had a `Post` route defined like so:\n\n```js\nimport Route from '@ember/routing/route';\n\nexport default Route.extend({\n  serialize(model) {\n    return { post_id: model.id };\n  }\n});\n```\n\nYou would need to remove that function and inline it into your `routes.js` map, which is loaded pre-emptively with the application:\n\n```js\nfunction serializePost(model) {\n  return { post_id: model.id };\n}\n\nexport default buildRoutes(function() {\n  this.route('post', { serialize: serializePost });\n});\n```\n\nNote that route serializers are unique to Engines and won't work in normal applications. In a normal Ember application you should continue to use `Route#serialize`.\n\n#### Loading / Error Substates\n\nThe loading and error substates work in a similar fashion to [substates in a normal Ember app](https://guides.emberjs.com/v3.0.0/routing/loading-and-error-substates/). The only difference is that lazily loaded Engines will enter a loading state while the assets for the Engine are loaded and can enter an error state when an asset fails to load.\n\n### Accessing Engine Configuration Settings\n\nAs in an application, you can provide configuration settings for your\nengine in `config/environment.js`. You can access these settings in a\ncouple different ways.\n\nThe simplest method is to import these settings:\n\n```js\n// addon/engine.js\nimport config from './config/environment';\n\nconsole.log(config.modulePrefix);\n```\n\nConfiguration settings are also registered with the key `config:environment` and\ncan be looked up given an engine instance. For example:\n\n```js\n// addon/instance-initializers/hello-instance.js\nexport function initialize(engineInstance) {\n  let config = engineInstance.resolveRegistration('config:environment');\n  console.log('modulePrefix', config.modulePrefix);\n}\n\nexport default {\n  name: 'hello-instance',\n  initialize: initialize\n};\n```\n\n## Built Engine Output\n\n### Eager Engines\n\nEager engines are built approximately the same as existing addons. Differences\nare limited to consolidating the namespace of `app` code inside of an engine\ninto the engine's namespace instead of the host application.\n\nBeyond that it adds in a configuration module for the engine, and nothing else.\nIt is a remarkably straightforward process.\n\n### Lazy Engines\n\nLazy engines are built in the same way as eager engines, but their assets are\nnot combined back into the host application's `vendor.js` file. This means that\nthey are run through a separate and unique build process from what a default\naddon will go through, though it reaches out to the upstream implementation in\nEmber CLI where possible.\n\nA lazy engine's output (`lazy-engine`) looks like this:\n```\ndist\n├── assets\n│   ├── host-application.css\n│   ├── host-application.js\n│   ├── vendor.css\n│   └── vendor.js\n├── crossdomain.xml\n├── engines-dist\n│   └── lazy-engine\n│       ├── assets\n│       │   ├── engine-vendor.css\n│       │   ├── engine-vendor.js\n│       │   ├── engine.css\n│       │   └── engine.js\n│       └── public-asset.jpg\n├── index.html\n└── robots.txt\n```\n\n#### `/addon/routes.js`\n\nThe `routes.js` file and anything it `import`s must be present at boot time of\nthe host application. It will be bundled into the host application's `vendor.js`\nfile. This location should be considered `undefined` behavior and should not be\nrelied upon as it may change in the future.\n\nIts module name inside of the host application will be `lazy-engine/routes`. Any\n`import`s will also be in the `lazy-engine` module path.\n\n#### `/app`\n\nAssets in this folder don't make sense and will be ignored as they break the\nisolation guarantees of engines.\n\n#### `/addon`\n\nJavaScript assets in this folder will be processed as per normal addon behavior\nexcept that they will end up inside of the `engine.js` file. Their module\ndefinition will be rooted to the engine name.\n\nFor example, `/addon/routes/application.js` will result in a JavaScript module\nnamed `lazy-engine/routes/application` inside of the\n`/dist/engines-dist/lazy-engine/engine.js` file.\n\n#### `/addon/templates`\n\nTemplates will be compiled by your engine but they must include\n`ember-cli-htmlbars` inside of `dependencies` in the engine's `package.json`.\n\nAs an example, `/addon/templates/application.hbs` will result in a JavaScript\nmodule named `lazy-engine/templates/application` inside of the\n`/dist/engines-dist/lazy-engine/engine.js` file.\n\n#### `/addon/styles/**/*.css`\n\nCSS files will be built similarly to how they are processed inside of typical\nadddons. Typical addon behavior is as follows:\n\n1. All nested addons are processed. Each of them may return a `style` tree. By\ndefault these style trees only contain the contents of `addon/styles/addon.css`.\nThe contents of the `addon/styles/addon.css` file is moved inside of the\nBroccoli tree to `${addon-name}.css`. This can be modified if the addon\nspecifies a custom `treeForStyle` hook.\n2. All top-level addons (those directly depended upon by the host) have all of\n`addon/styles/**/*.css` included into the host's `vendor.css` file. For example\n`addon/styles/foo.css` will appear in the output Broccoli tree at `foo.css`.\n3. If you name a CSS file in one of the top-level addons the same as an addon\nname (e.g. addon name is `alpha`), any top-level addon which has a CSS file\nof the same name as that addon (`alpha.css`) and is provided by an addon\nlexicographically after it (`zeta`) will clobber the contents of\n`alpha/addon/styles/addon.css` (from anywhere in the dependency graph) with\n`zeta/addon/styles/alpha.css`. (This is also a possible consequence of DAG\ntopsorting.)\n\nLazy engines will use a variation of this approach:\n\n1. The engine itself will be treated as if it is a top-level dependency. This\nmeans that `addon/styles/**/*.css` will end up inside of `engine.css`.\n2. Child addons of a lazy engine will be treated as if they are top-level\naddons. This means that they will have their `treeForStyle` hook executed and\nthe result of that hook will be merged into `engine-vendor.css` in\nDAG/lexicographic order.\n3. Nested lazy engine boundaries will not be crossed when calculating the child\n`treeForStyle` hook.\n\n#### `/public`\n\nAssets appearing in the public folder will appear at the root of the engine\noutput with no transformation. For example `/public/public-asset.jpg` appears at\nthe root level of the `/dist/engines-dist/lazy-engine/` output folder. Assets in\nthis folder have no default behavior and you are responsible for any custom\nbehavior.\n\n#### Asset Manifest\n\nFurther, the engine must enumerate its primary assets (JS and CSS) in order to\nbe loaded by the asset loading service. That will be generated at\n`/dist/asset-manifest.json` at build time. It will also by default be inserted\ninto a meta tag config inside of the host application's `index.html`.\n\n### Nested Eager Engines\n\nNested eager engines will be built into their host engine or application.\nModules will be deduplicated within the engine boundary and with the host\napplication.\n\n### Nested Lazy Engines\n\nNested lazy engines will be promoted to `/dist/engines-dist/` folder in the\nbuild output. Module deduplication will only be done with the host application.\n\n## Consuming Engines\n\nEngines that are published as separate addons should be installed like any\nother addon:\n\n```\nember install <engine-name>\n```\n\nAs mentioned above, engines can also exist as in-repo addons, in which case\nyou just need to ensure that this addon (`ember-engines`) has been installed\nin your main project.\n\n### Route-less Engines\n\nRoute-less engines can be rendered in a template using the `{{mount}}`\nkeyword.\n\n#### Using `{{mount}}` in Templates\n\nRoute-less engines can be mounted in templates using the `{{mount}}` keyword.\nFor example, the following template renders the `ember-chat` engine:\n\n```hbs\n{{mount \"ember-chat\"}}\n```\n\nCurrently, the engine name is the only argument that can be passed to\n`{{mount}}`.\n\n### Routable Engines\n\n#### Mounting Engines in your Route Map\n\nRoutable engines should be mounted in your router's route map using the\n`mount()` method. For example:\n\n```js\nimport Route from '@ember/routing/route'\nimport config from './config/environment';\n\nconst Router = Router.extend({\n  location: config.locationType\n});\n\nRouter.map(function() {\n  this.route('blogs', function() {\n    // Mount the main blog at /blogs/ember-blog\n    this.mount('ember-blog');\n\n    // Mount the hr blog at /blogs/hr-blog\n    this.mount('ember-blog', { as: 'hr-blog' });\n\n    // Mount the admin blog at /blogs/special-admin-blog-here\n    this.mount('ember-blog', { as: 'admin-blog', path: '/special-admin-blog-here' });\n  });\n});\n\nexport default Router;\n```\n\nThe above example mounts three different instances of the `ember-blog` engine\nwithin the `blogs` route.\n\nThe engine mounted with `this.mount('ember-blog')` will have a root path of\n`/blogs/ember-blog` and its root route can be referenced as `ember-blog`.\n\nThe engine mounted with `this.mount('ember-blog', { as: 'hr-blog' })` will have\na root path of `/blogs/hr-blog` and its root route can be referenced as\n`hr-blog`.\n\nThe engine mounted with `this.mount('ember-blog', { as: 'admin-blog', path:\n'/special-admin-blog-here' })` will have a root path of\n`/blogs/special-admin-blog-here` and its root route can be referenced as\n`admin-blog`.\n\n_Note: The above example is not very practical currently without a method to\nconfigure individual instances of `ember-blog`._\n\n### Providing Dependencies to Engines\n\nApplications or engines that contain an engine must provide mappings that\nfulfill the dependencies required by that engine.\n\nFor example, the following engine expects its parent to provide `store` and\n`session` services:\n\n```js\nimport Engine from 'ember-engines/engine';\nimport Resolver from 'ember-resolver';\n\nexport default Engine.extend({\n  modulePrefix: 'ember-blog',\n\n  Resolver,\n\n  dependencies: {\n    services: [\n      'store',\n      'session'\n    ]\n  }\n});\n```\n\nAn application that contains this engine must explicitly fulfill these\ndependencies. For example:\n\n```js\nimport Application from '@ember/application';\nimport Resolver from './resolver';\nimport loadInitializers from 'ember-load-initializers';\nimport config from './config/environment';\n\nconst App = Application.extend({\n  modulePrefix: config.modulePrefix,\n  podModulePrefix: config.podModulePrefix,\n  Resolver,\n\n  engines: {\n    emberBlog: {\n      dependencies: {\n        services: [\n          'store',\n          {'session': 'user-session'}\n        ]\n      }\n    }\n  }\n});\n\nloadInitializers(App, config.modulePrefix);\n\nexport default App;\n```\n\nNote that the app's `store` service is directly mapped to the engine's `store`\nservice, while the app's `user-session` service is mapped to the engine's\n`session` service.\n\nAlso note that multiple engines can be configured per parent application/engine,\nand that each engine name should be camelCased (`emberBlog` instead of\n`ember-blog`).\n\n### Unit/Integration testing for in repo-engines\n\nTo test components declared inside an in-repo engine, you need to set a custom resolver with the engine's prefix.\n\nAssuming you have an in-repo engine called `appointments-manager` and it has a component `date-picker`. The\nfollowing would be the setup to test such component from the host app:\n\n```js\n// host-app/tests/integration/components/date-picker-test.js\n\nimport { moduleForComponent, test } from 'ember-qunit';\nimport hbs from 'htmlbars-inline-precompile';\nimport engineResolverFor from 'ember-engines/test-support/engine-resolver-for';\n\nconst resolver = engineResolverFor('appointments-manager');\n\nmoduleForComponent('date-picker', 'Integration | Component | Date picker', {\n  integration: true,\n  resolver\n});\n\ntest('renders text', function(assert) {\n  this.render(hbs`{{date-picker}}`);\n\n  assert.equal(this.$().text().trim(), 'una fecha');\n});\n```\n\n**Note: you could create a helper and then use it like `Resolver from ../helpers/appointments-manager/resolver`**\n\n### Testing for standalone engines\n\nIf you have a lazy engine, you'll need to edit your `tests/test-helper.js` like this:\n\n```js\nimport Application from '../app';\nimport config from '../config/environment';\nimport { setApplication } from '@ember/test-helpers';\nimport { start } from 'ember-qunit';\nimport preloadAssets from 'ember-asset-loader/test-support/preload-assets';\nimport manifest from '<app-name>/config/asset-manifest';\n\nsetApplication(Application.create(config.APP));\n\npreloadAssets(manifest).then(start); // This ensures all engine resources are loaded before the tests\n```\n\nThis should be enough to make integration & acceptance tests work.\nFor unit tests, you'll need to use a custom resolver, as described in [Unit/Integration testing for standalone engines](#unitintegration-testing-for-in-repo-engines).\n\n## Demo Projects\n\n* [ember-engines-demo](https://github.com/dgeb/ember-engines-demo) - an example of a parent application (consumer).\n  * ember-chat-engine - an example of a route-less engine that is an in-repo addon.\n* [ember-blog-engine](https://github.com/dgeb/ember-blog-engine) - an example of a routable engine that is a separate addon project.\n\n## Contributing\n\n### Installation\n\n* `git clone` this repository\n* `npm install`\n\n### Running\n\n* `ember server`\n* Visit your app at http://localhost:4200.\n\n### Running Tests\n\n* `npm test` (Runs `ember try:testall` to test your addon against multiple Ember versions)\n* `ember test`\n* `ember test --server`\n\n### Building\n\n* `ember build`\n\nFor more information on using ember-cli, visit [http://www.ember-cli.com/](http://www.ember-cli.com/).\n\n## License\n\nCopyright 2015-2018 Dan Gebhardt and Robert Jackson. MIT License (see LICENSE.md for details).\n","readmeFilename":"README.md","gitHead":"daf4b2cbb8f74cf459fd72ad8cd0133e3331bbe2","bugs":{"url":"https://github.com/ember-engines/ember-engines/issues"},"homepage":"https://github.com/ember-engines/ember-engines#readme","_id":"@buschtoens/ember-engines@0.5.26-beta.2","_npmVersion":"6.5.0","_nodeVersion":"11.6.0","_npmUser":{"name":"buschtoens","email":"buschtoens@gmail.com"},"dist":{"integrity":"sha512-9n3woSoYH51KQ5keEqkUi/RNNA61m6GRIsRXyuztjULBT+jwHxMAdadN/tBORAh51ZR7Pas0UIUyHqseDJoOZw==","shasum":"060c26d84a1d8d31874bcababff6fb77029e8b36","tarball":"https://registry.npmjs.org/@buschtoens/ember-engines/-/ember-engines-0.5.26-beta.2.tgz","fileCount":74,"unpackedSize":391616,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcNgObCRA9TVsSAnZWagAAuHsP+gJ+UqfySINIynmF4mHh\nvHHqPfucjJ01QA4p870pw9WLUG7ZQHIVb/lydpujUQ/WPN1ltwDaKKe+t37w\nnqT9EdeGHS/gNKBkTz5AKmXLy28B1/fYnJNn6xurqHBToF76m/tYb2HCW2rB\nVeOYg/oCrBrQlT1wOG98ZKg+GukA3b4bboTGLib1ZIxq3o14n8zSvoMRe5bI\nrcz/FQcEoA0dSS4wSNrJF1yl9cuFDIzVNZVtJAhQ26C59qH1Q4bi8RQsUCCf\nvhUP3LyXuP7pZU6/mEeP3R+Tal9yWQLzEpHEzggjD+eXq717pjZVkGb9Fa1D\nTmLSZ4W2ICyNQ9wn2ZjpkhZlfbqHZnUzbT4eYGSpaZstZaqpX1R95Ld2jf6L\nzFn/IGdJGhN4/UIZjQhaExUrPOR4XkGEaP2aP4x3kAHeZu8vfyaQA2kym7IR\nBJ+6V8cRjbMSXxaKqqb8qPv5yln3tpapNQc6Um45xAlxwnNu20tb9SMI2/U3\nEh4bdTOcXE8EA5fyhRuq07ozo8aU7XfvZIJelDU+dT/UqGP6GQSfCW1D8OEP\niBYbtBTdk30BA2wKFhlpfeiTowy4ncorMtu+0y4GINJE6s8yM1hBcMBM5N98\nE/F/uPlq276vwqfQJjoZTGwUq9qY4yxwsTFlUXPz8qnrgdmTmTniU6LfPrBO\nsaYk\r\n=WW/w\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIDi9/DQUmja4lBFGZ6aWrfbHdZ6QbgbNRojtGxRmGvB0AiEAxSVFR6hQFUDH5a5/i7ua7q9s9A11UxSJH44HZG+VWOg="}]},"maintainers":[{"name":"buschtoens","email":"buschtoens@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/ember-engines_0.5.26-beta.2_1547043739136_0.596758657446177"},"_hasShrinkwrap":false},"0.7.2-rc.1":{"name":"@buschtoens/ember-engines","version":"0.7.2-rc.1","description":"Experimental support for Ember Engines","directories":{"doc":"doc","test":"tests"},"scripts":{"build":"ember build","changelog":"lerna-changelog","lint:hbs":"ember-template-lint .","lint:js":"eslint ./*.js addon addon-test-support app config lib tests","start":"ember serve","test":"ember test","test:all":"ember try:each","test:ember":"ember try:one $EMBER_TRY_SCENARIO test --skip-cleanup","test:emberall":"ember try:each --skip-cleanup","test:lint":"eslint index.js addon addon-test-support app bin config lib node-tests tests vendor","test:lint:fix":"eslint --fix index.js addon addon-test-support app bin config lib node-tests tests vendor","test:node":"mocha 'node-tests/**/*-test.js' --reporter tap","test:node:debug":"mocha --inspect-brk 'node-tests/**/*-test.js' --reporter tap","test:windows":"ember try:one %EMBER_TRY_SCENARIO% test --skip-cleanup","test:node:dev":"BUILD_DEV=true testem -f testem-node.js","test:null":"echo 'no appropriate changes detected, not running tests'"},"repository":{"type":"git","url":"git+https://github.com/ember-engines/ember-engines.git"},"authors":["Dan Gebhardt","Robert Jackson"],"license":"MIT","devDependencies":{"@ember/jquery":"^0.6.0","@ember/optional-features":"^0.7.0","broccoli-asset-rev":"^3.0.0","chai":"^4.2.0","common-tags":"^1.8.0","eager-blog":"link:./tests/dummy/lib/eager-blog","ember-blog":"link:./tests/dummy/lib/ember-blog","ember-chat":"link:./tests/dummy/lib/ember-chat","ember-cli":"~3.7.1","ember-cli-addon-tests":"^0.11.0","ember-cli-app-version":"^3.2.0","ember-cli-dependency-checker":"^3.1.0","ember-cli-htmlbars":"^3.0.1","ember-cli-htmlbars-inline-precompile":"^2.1.0","ember-cli-inject-live-reload":"^2.0.1","ember-cli-sri":"^2.1.1","ember-cli-template-lint":"^1.0.0-beta.1","ember-cli-uglify":"^2.1.0","ember-compatibility-helpers":"^1.2.0","ember-disable-prototype-extensions":"^1.1.3","ember-export-application-global":"^2.0.0","ember-load-initializers":"^2.0.0","ember-qunit":"^4.4.0","ember-resolver":"^5.1.1","ember-sinon":"^3.1.0","ember-source":"~3.8.0","ember-source-channel-url":"^1.1.0","ember-try":"^1.1.0","eslint":"^5.14.1","eslint-config-prettier":"^4.0.0","eslint-plugin-ember":"^6.2.0","eslint-plugin-node":"^8.0.1","eslint-plugin-prettier":"^3.0.1","execa":"^1.0.0","fixturify":"^0.3.4","fs-extra":"^7.0.1","lerna-changelog":"^0.8.2","loader.js":"^4.7.0","mocha":"^6.0.0","prettier":"^1.16.4","walk-sync":"^1.1.3"},"keywords":["ember-addon"],"dependencies":{"amd-name-resolver":"1.3.1","babel-plugin-compact-reexports":"^1.1.0","broccoli-babel-transpiler":"^7.1.2","broccoli-concat":"^3.7.3","broccoli-debug":"^0.6.5","broccoli-dependency-funnel":"^2.1.2","broccoli-file-creator":"^2.1.1","broccoli-funnel":"^2.0.2","broccoli-merge-trees":"^3.0.2","broccoli-test-helper":"^2.0.0","calculate-cache-key-for-tree":"^1.1.0","ember-asset-loader":"^0.5.1","ember-cli-babel":"^7.4.3","ember-cli-preprocess-registry":"^3.1.2","ember-cli-string-utils":"^1.1.0","ember-cli-version-checker":"^3.0.1","ember-maybe-import-regenerator":"^0.1.6","lodash":"^4.17.11"},"engines":{"node":"6.* || 8.* || >= 10.*"},"ember-addon":{"configPath":"tests/dummy/config","before":"broccoli-asset-rev"},"readme":"# ember-engines [![npm version](https://badge.fury.io/js/ember-engines.svg)](https://badge.fury.io/js/ember-engines) [![Build Status](https://travis-ci.org/ember-engines/ember-engines.svg?branch=master)](https://travis-ci.org/ember-engines/ember-engines)\n\nThis Ember addon implements the functionality described in the [Ember Engines\nRFC](https://github.com/emberjs/rfcs/blob/master/text/0010-engines.md). Engines allow multiple logical\napplications to be composed together into a single application from the user's\nperspective.\n\nThis addon must be installed in any ember-cli projects that function as either\nconsumers or providers of engines. The following functionality is supported:\n\n* Routable engines which can be mounted at specific routes in a routing map, and\n  which can contain routes of their own.\n* Route-less engines, which can be rendered in a template using the `{{mount}}`\n  keyword.\n* Sharing of dependencies from parents (applications or other engines) to\n  contained engines. Shared dependencies are currently limited to services\n  and route paths.\n* Lazy loading of engines.\n\nThe following functionality will soon be supported:\n\n* Route serializer modules that isolate serialization logic from the rest of\n  the route definition.\n\nSupport for the following concepts is under consideration:\n\n* Namespaced access to engine resources from applications.\n* Sharing of dependencies other than services and route paths.\n* Passing configuration attributes from an engine's parent.\n\n## Important Note about Compatibility and Stability\n\nThis addon should be considered experimental. But engines are production ready and many of the APIs are fully stable.\n\nThe [master branch of this addon](https://github.com/ember-engines/ember-engines)\nis being developed against the master branch of Ember and Ember-CLI, and should\nbe considered unstable. If you're planning to deploy to production, please use\none of the stable releases.\n\n[v0.5.15 or higher](https://github.com/ember-engines/ember-engines/tree/v0.5.15)\nis compatible with FastBoot 1.0+.\n\n[v0.5 of this addon](https://github.com/ember-engines/ember-engines/tree/v0.5.0)\nis compatible with v2.12.x of both Ember and Ember-CLI.\n\n[v0.4 of this addon](https://github.com/ember-engines/ember-engines/tree/v0.4.0)\nis compatible with v2.10.x of both Ember and Ember-CLI.\n\n[v0.3 of this addon](https://github.com/ember-engines/ember-engines/tree/v0.3)\nis compatible with v2.8.x of Ember. This is the first version of Ember in which\nthe required hooks for engines are available without a feature flag.\n\n## Introduction Video\n\n[![Introduction to Ember Engines at Global Ember Meetup](https://i.vimeocdn.com/video/559400541_640x360.jpg)](https://vimeo.com/157688181)\n\n## Installation\n\nFrom your Ember CLI project's root directory, run the following:\n\n```\nember install ember-engines\n```\n\nInstall the appropriate version of Ember as noted above.\n\n## Providing Engines\n\n### Creating Engines\n\nEngines can be created as separate addon projects or in-repo addons.\n\nSeparate addon projects can be created with the `addon` command:\n\n```\nember addon <engine-name>\n```\n\n_Note: As described in the RFC, ember-cli will hopefully support an `engine`\ncommand to get started more easily with engine projects._\n\nIn order to create an engine within an existing application's project, run the\n`in-repo-engine` generator:\n\n```\nember g in-repo-engine <engine-name>\n```\n\nDon't forget to install `ember-engines` and the appropriate version of Ember in\nyour project, as described above.\n\n### Lazy Loading Engines\n\nYou must also declare in your Engine's `index.js` file whether or not the engine should be lazy loaded. Until lazy loading is supported, this should be set to `false`:\n```js\nconst EngineAddon = require('ember-engines/lib/engine-addon');\nmodule.exports = EngineAddon.extend({\n  name: 'ember-blog',\n  lazyLoading: {\n    enabled: false\n  }\n});\n```\n\n### Routable Engines\n\nRoutable engines should declare their route map in a `routes.js` file within your engine's `addon` directory.\nFor example:\n\n```js\nimport buildRoutes from 'ember-engines/routes';\n\nexport default buildRoutes(function() {\n  this.route('new');\n\n  this.route('post', { path: 'post/:id' }, function() {\n    this.route('comments', function() {\n      this.route('comment', { path: ':id' });\n    });\n  });\n});\n```\n\nRoutable engines interact with the parent application's router as if they are\nan extension of the parent application. A routable engine's application route\nwill be mounted wherever specified by the parent's route map (its \"mountpoint\").\n\n### Route-less Engines\n\nRoute-less engines should define an `engine.js` as described above. Neither\n`router.js` nor `routes.js` should be defined. Route-less engines will be rendered as their application template\n(`templates/application.hbs`).\n\n### Declaring Dependencies\n\nYour engine should declare any dependencies that it expects from its parent.\nDependencies must be declared in the engine definition.\n\nFor example, the following engine requires a `store` service from its parent:\n\n```js\nimport Engine from 'ember-engines/engine';\nimport Resolver from 'ember-resolver';\nimport loadInitializers from 'ember-load-initializers';\nimport config from './config/environment';\n\nconst { modulePrefix } = config;\n\nconst Eng = Engine.extend({\n  modulePrefix,\n  Resolver,\n  dependencies: {\n    services: [\n      'store'\n    ]\n  }\n});\n\nloadInitializers(Eng, modulePrefix);\n\nexport default Eng;\n```\n\nCurrently, only services and route paths (see below) can be shared across the\nparent/engine boundary.\n\n### Linking To External Routes\n\nLinking to routes outside of an Engine's isolated context is currently supported\nby defining \"external routes\" as dependencies of your Engine.\n\nYou specify **what** external things your Engine wants to link to by providing\nan array of names like so:\n\n```js\n// ember-blog/addon/engine.js\nexport default Engine.extend({\n  // ...\n  dependencies: {\n    externalRoutes: [\n      'home',\n      'settings'\n    ]\n  }\n});\n```\n\nThe Engine's consumer is then responsible for defining **where** those things are\nlocated via a route path:\n\n```js\n// dummy/app/app.js\nimport Application from '@ember/application';\nimport Resolver from './resolver';\nimport loadInitializers from 'ember-load-initializers';\nimport config from './config/environment';\n\nconst App = Application.extend({\n  modulePrefix: config.modulePrefix,\n  podModulePrefix: config.podModulePrefix,\n  Resolver,\n\n  engines: {\n    emberBlog: {\n      dependencies: {\n        externalRoutes: {\n          home: 'home.index',\n          settings: 'settings.blog.index'\n        }\n      }\n    }\n  }\n});\n```\n\nYou can then use those external routes either programmatically or within a\ntemplate like so:\n\n```hbs\n{{#link-to-external 'home'}}Go home{{/link-to-external}}\n```\n\n```js\n// ember-blog/addon/some-route.js\nthis.transitionToExternal('settings');\n```\n\nFor further documentation on this subject, view the [Engine Linking RFC](https://github.com/emberjs/rfcs/pull/122).\n\n### Lazy-Loading Routing Considerations\n\nWhen routing into an Engine that is lazily loaded there are some special considerations and subtle differences from how routing works in a normal Ember application.\n\n#### Serialization of URLs\n\nSince the links to your Engine are constructed before the Engine itself is loaded, you need to make sure the application has the necessary code to serialize data into the URLs. To that end, you need to replace any [`Route#serialize`](http://emberjs.com/api/classes/Ember.Route.html#method_serialize) functions with route serializers, as defined in [the Route Serializers RFC](https://github.com/emberjs/rfcs/blob/master/text/0120-route-serializers.md).\n\nFor example, if you had a `Post` route defined like so:\n\n```js\nimport Route from '@ember/routing/route';\n\nexport default Route.extend({\n  serialize(model) {\n    return { post_id: model.id };\n  }\n});\n```\n\nYou would need to remove that function and inline it into your `routes.js` map, which is loaded pre-emptively with the application:\n\n```js\nfunction serializePost(model) {\n  return { post_id: model.id };\n}\n\nexport default buildRoutes(function() {\n  this.route('post', { serialize: serializePost });\n});\n```\n\nNote that route serializers are unique to Engines and won't work in normal applications. In a normal Ember application you should continue to use `Route#serialize`.\n\n#### Loading / Error Substates\n\nThe loading and error substates work in a similar fashion to [substates in a normal Ember app](https://guides.emberjs.com/v3.0.0/routing/loading-and-error-substates/). The only difference is that lazily loaded Engines will enter a loading state while the assets for the Engine are loaded and can enter an error state when an asset fails to load.\n\n### Accessing Engine Configuration Settings\n\nAs in an application, you can provide configuration settings for your\nengine in `config/environment.js`. You can access these settings in a\ncouple different ways.\n\nThe simplest method is to import these settings:\n\n```js\n// addon/engine.js\nimport config from './config/environment';\n\nconsole.log(config.modulePrefix);\n```\n\nConfiguration settings are also registered with the key `config:environment` and\ncan be looked up given an engine instance. For example:\n\n```js\n// addon/instance-initializers/hello-instance.js\nexport function initialize(engineInstance) {\n  let config = engineInstance.resolveRegistration('config:environment');\n  console.log('modulePrefix', config.modulePrefix);\n}\n\nexport default {\n  name: 'hello-instance',\n  initialize: initialize\n};\n```\n\n## Built Engine Output\n\n### Eager Engines\n\nEager engines are built approximately the same as existing addons. Differences\nare limited to consolidating the namespace of `app` code inside of an engine\ninto the engine's namespace instead of the host application.\n\nBeyond that it adds in a configuration module for the engine, and nothing else.\nIt is a remarkably straightforward process.\n\n### Lazy Engines\n\nLazy engines are built in the same way as eager engines, but their assets are\nnot combined back into the host application's `vendor.js` file. This means that\nthey are run through a separate and unique build process from what a default\naddon will go through, though it reaches out to the upstream implementation in\nEmber CLI where possible.\n\nA lazy engine's output (`lazy-engine`) looks like this:\n```\ndist\n├── assets\n│   ├── host-application.css\n│   ├── host-application.js\n│   ├── vendor.css\n│   └── vendor.js\n├── crossdomain.xml\n├── engines-dist\n│   └── lazy-engine\n│       ├── assets\n│       │   ├── engine-vendor.css\n│       │   ├── engine-vendor.js\n│       │   ├── engine.css\n│       │   └── engine.js\n│       └── public-asset.jpg\n├── index.html\n└── robots.txt\n```\n\n#### `/addon/routes.js`\n\nThe `routes.js` file and anything it `import`s must be present at boot time of\nthe host application. It will be bundled into the host application's `vendor.js`\nfile. This location should be considered `undefined` behavior and should not be\nrelied upon as it may change in the future.\n\nIts module name inside of the host application will be `lazy-engine/routes`. Any\n`import`s will also be in the `lazy-engine` module path.\n\n#### `/app`\n\nAssets in this folder don't make sense and will be ignored as they break the\nisolation guarantees of engines.\n\n#### `/addon`\n\nJavaScript assets in this folder will be processed as per normal addon behavior\nexcept that they will end up inside of the `engine.js` file. Their module\ndefinition will be rooted to the engine name.\n\nFor example, `/addon/routes/application.js` will result in a JavaScript module\nnamed `lazy-engine/routes/application` inside of the\n`/dist/engines-dist/lazy-engine/engine.js` file.\n\n#### `/addon/templates`\n\nTemplates will be compiled by your engine but they must include\n`ember-cli-htmlbars` inside of `dependencies` in the engine's `package.json`.\n\nAs an example, `/addon/templates/application.hbs` will result in a JavaScript\nmodule named `lazy-engine/templates/application` inside of the\n`/dist/engines-dist/lazy-engine/engine.js` file.\n\n#### `/addon/styles/**/*.css`\n\nCSS files will be built similarly to how they are processed inside of typical\nadddons. Typical addon behavior is as follows:\n\n1. All nested addons are processed. Each of them may return a `style` tree. By\ndefault these style trees only contain the contents of `addon/styles/addon.css`.\nThe contents of the `addon/styles/addon.css` file is moved inside of the\nBroccoli tree to `${addon-name}.css`. This can be modified if the addon\nspecifies a custom `treeForStyle` hook.\n2. All top-level addons (those directly depended upon by the host) have all of\n`addon/styles/**/*.css` included into the host's `vendor.css` file. For example\n`addon/styles/foo.css` will appear in the output Broccoli tree at `foo.css`.\n3. If you name a CSS file in one of the top-level addons the same as an addon\nname (e.g. addon name is `alpha`), any top-level addon which has a CSS file\nof the same name as that addon (`alpha.css`) and is provided by an addon\nlexicographically after it (`zeta`) will clobber the contents of\n`alpha/addon/styles/addon.css` (from anywhere in the dependency graph) with\n`zeta/addon/styles/alpha.css`. (This is also a possible consequence of DAG\ntopsorting.)\n\nLazy engines will use a variation of this approach:\n\n1. The engine itself will be treated as if it is a top-level dependency. This\nmeans that `addon/styles/**/*.css` will end up inside of `engine.css`.\n2. Child addons of a lazy engine will be treated as if they are top-level\naddons. This means that they will have their `treeForStyle` hook executed and\nthe result of that hook will be merged into `engine-vendor.css` in\nDAG/lexicographic order.\n3. Nested lazy engine boundaries will not be crossed when calculating the child\n`treeForStyle` hook.\n\n#### `/public`\n\nAssets appearing in the public folder will appear at the root of the engine\noutput with no transformation. For example `/public/public-asset.jpg` appears at\nthe root level of the `/dist/engines-dist/lazy-engine/` output folder. Assets in\nthis folder have no default behavior and you are responsible for any custom\nbehavior.\n\n#### Asset Manifest\n\nFurther, the engine must enumerate its primary assets (JS and CSS) in order to\nbe loaded by the asset loading service. That will be generated at\n`/dist/asset-manifest.json` at build time. It will also by default be inserted\ninto a meta tag config inside of the host application's `index.html`.\n\n#### Nested addon deduplication\nUse `EMBER_ENGINES_ADDON_DEDUPE` environment variable to deduplicate the nested\naddons of lazy engine which are also host app addons.\nMore details at [#595](https://github.com/ember-engines/ember-engines/pull/595).\n\n### Nested Eager Engines\n\nNested eager engines will be built into their host engine or application.\nModules will be deduplicated within the engine boundary and with the host\napplication.\n\n### Nested Lazy Engines\n\nNested lazy engines will be promoted to `/dist/engines-dist/` folder in the\nbuild output. Module deduplication will only be done with the host application.\n\n## Consuming Engines\n\nEngines that are published as separate addons should be installed like any\nother addon:\n\n```\nember install <engine-name>\n```\n\nAs mentioned above, engines can also exist as in-repo addons, in which case\nyou just need to ensure that this addon (`ember-engines`) has been installed\nin your main project.\n\n### Route-less Engines\n\nRoute-less engines can be rendered in a template using the `{{mount}}`\nkeyword.\n\n#### Using `{{mount}}` in Templates\n\nRoute-less engines can be mounted in templates using the `{{mount}}` keyword.\nFor example, the following template renders the `ember-chat` engine:\n\n```hbs\n{{mount \"ember-chat\"}}\n```\n\nCurrently, the engine name is the only argument that can be passed to\n`{{mount}}`.\n\n### Routable Engines\n\n#### Mounting Engines in your Route Map\n\nRoutable engines should be mounted in your router's route map using the\n`mount()` method. For example:\n\n```js\nimport Route from '@ember/routing/route'\nimport config from './config/environment';\n\nconst Router = Router.extend({\n  location: config.locationType\n});\n\nRouter.map(function() {\n  this.route('blogs', function() {\n    // Mount the main blog at /blogs/ember-blog\n    this.mount('ember-blog');\n\n    // Mount the hr blog at /blogs/hr-blog\n    this.mount('ember-blog', { as: 'hr-blog' });\n\n    // Mount the admin blog at /blogs/special-admin-blog-here\n    this.mount('ember-blog', { as: 'admin-blog', path: '/special-admin-blog-here' });\n  });\n});\n\nexport default Router;\n```\n\nThe above example mounts three different instances of the `ember-blog` engine\nwithin the `blogs` route.\n\nThe engine mounted with `this.mount('ember-blog')` will have a root path of\n`/blogs/ember-blog` and its root route can be referenced as `ember-blog`.\n\nThe engine mounted with `this.mount('ember-blog', { as: 'hr-blog' })` will have\na root path of `/blogs/hr-blog` and its root route can be referenced as\n`hr-blog`.\n\nThe engine mounted with `this.mount('ember-blog', { as: 'admin-blog', path:\n'/special-admin-blog-here' })` will have a root path of\n`/blogs/special-admin-blog-here` and its root route can be referenced as\n`admin-blog`.\n\n_Note: The above example is not very practical currently without a method to\nconfigure individual instances of `ember-blog`._\n\n### Providing Dependencies to Engines\n\nApplications or engines that contain an engine must provide mappings that\nfulfill the dependencies required by that engine.\n\nFor example, the following engine expects its parent to provide `store` and\n`session` services:\n\n```js\nimport Engine from 'ember-engines/engine';\nimport Resolver from 'ember-resolver';\n\nexport default Engine.extend({\n  modulePrefix: 'ember-blog',\n\n  Resolver,\n\n  dependencies: {\n    services: [\n      'store',\n      'session'\n    ]\n  }\n});\n```\n\nAn application that contains this engine must explicitly fulfill these\ndependencies. For example:\n\n```js\nimport Application from '@ember/application';\nimport Resolver from './resolver';\nimport loadInitializers from 'ember-load-initializers';\nimport config from './config/environment';\n\nconst App = Application.extend({\n  modulePrefix: config.modulePrefix,\n  podModulePrefix: config.podModulePrefix,\n  Resolver,\n\n  engines: {\n    emberBlog: {\n      dependencies: {\n        services: [\n          'store',\n          {'session': 'user-session'}\n        ]\n      }\n    }\n  }\n});\n\nloadInitializers(App, config.modulePrefix);\n\nexport default App;\n```\n\nNote that the app's `store` service is directly mapped to the engine's `store`\nservice, while the app's `user-session` service is mapped to the engine's\n`session` service.\n\nAlso note that multiple engines can be configured per parent application/engine,\nand that each engine name should be camelCased (`emberBlog` instead of\n`ember-blog`).\n\n### Unit/Integration testing for in repo-engines\n\nTo test components declared inside an in-repo engine, you need to set a custom resolver with the engine's prefix.\n\nAssuming you have an in-repo engine called `appointments-manager` and it has a component `date-picker`. The\nfollowing would be the setup to test such component from the host app:\n\n```js\n// host-app/tests/integration/components/date-picker-test.js\n\nimport { moduleForComponent, test } from 'ember-qunit';\nimport hbs from 'htmlbars-inline-precompile';\nimport engineResolverFor from 'ember-engines/test-support/engine-resolver-for';\n\nconst resolver = engineResolverFor('appointments-manager');\n\nmoduleForComponent('date-picker', 'Integration | Component | Date picker', {\n  integration: true,\n  resolver\n});\n\ntest('renders text', function(assert) {\n  this.render(hbs`{{date-picker}}`);\n\n  assert.equal(this.$().text().trim(), 'una fecha');\n});\n```\n\n**Note: you could create a helper and then use it like `Resolver from ../helpers/appointments-manager/resolver`**\n\n### Testing for standalone engines\n\nIf you have a lazy engine, you'll need to edit your `tests/test-helper.js` like this:\n\n```js\nimport Application from '../app';\nimport config from '../config/environment';\nimport { setApplication } from '@ember/test-helpers';\nimport { start } from 'ember-qunit';\nimport preloadAssets from 'ember-asset-loader/test-support/preload-assets';\nimport manifest from '<app-name>/config/asset-manifest';\n\nsetApplication(Application.create(config.APP));\n\npreloadAssets(manifest).then(start); // This ensures all engine resources are loaded before the tests\n```\n\nThis should be enough to make integration & acceptance tests work.\nFor unit tests, you'll need to use a custom resolver, as described in [Unit/Integration testing for standalone engines](#unitintegration-testing-for-in-repo-engines).\n\n## Demo Projects\n\n* [ember-engines-demo](https://github.com/dgeb/ember-engines-demo) - an example of a parent application (consumer).\n  * ember-chat-engine - an example of a route-less engine that is an in-repo addon.\n* [ember-blog-engine](https://github.com/dgeb/ember-blog-engine) - an example of a routable engine that is a separate addon project.\n\n## Contributing\n\n### Installation\n\n* `git clone` this repository\n* `npm install`\n\n### Running\n\n* `ember server`\n* Visit your app at http://localhost:4200.\n\n### Running Tests\n\n* `npm test` (Runs `ember try:testall` to test your addon against multiple Ember versions)\n* `ember test`\n* `ember test --server`\n\n### Building\n\n* `ember build`\n\nFor more information on using ember-cli, visit [http://www.ember-cli.com/](http://www.ember-cli.com/).\n\n## License\n\nCopyright 2015-2018 Dan Gebhardt and Robert Jackson. MIT License (see LICENSE.md for details).\n","readmeFilename":"README.md","gitHead":"13242288bdaa0e27508dd16d33584a02c38ede64","bugs":{"url":"https://github.com/ember-engines/ember-engines/issues"},"homepage":"https://github.com/ember-engines/ember-engines#readme","_id":"@buschtoens/ember-engines@0.7.2-rc.1","_nodeVersion":"12.1.0","_npmVersion":"6.9.0","dist":{"integrity":"sha512-CiUtGIn/gGp7b3iK0147W2UsX6AeYt0Dv2LtJvh33UH+1+sH9SWyyYrfAUB7bsDZ6JU+UmHLas9sAYtrAI8DqQ==","shasum":"37fbe9c305754bc557b59fcd0be67b6e12425e8a","tarball":"https://registry.npmjs.org/@buschtoens/ember-engines/-/ember-engines-0.7.2-rc.1.tgz","fileCount":56,"unpackedSize":103209,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJc7SXhCRA9TVsSAnZWagAAW/0P/39zWM4vaeFkaogDFDaQ\npdVWjSKy6iCm7Ut2lwRBM3Brk4gJkdeQxZAzsUY/WYkzJuvoQR0wcCjaAnxZ\n4tLIWdRwkhwjRjM7ajG+p+LGd0mpW8Q4ThjePxP5UnUGjt2nhuo3Z7p5XJcZ\n469ezxQSG0W+9qVVGGJ8CGYJE+y35GAtxqjLshxkMlInp0CyBnn6abPH5koc\ndBsTKMRjs9Ud54Dze2t0dLdv5Xl9dfqhlwY9Tt001OGDakAA8OrJOWZmgK1q\naAeYDHje7dQNe36piZXcvj326vI4ZwWsdez0lnseYPVO7EWh7YBhpD5tIPMp\nTA3X+Uba0oHXfPK/0w3cGE3348i583xr2AF/eoMH+0Tp3Fk+xicIde748IjQ\nFjCMCuaADk+1vjuvWrhknMmY42qfdjdXNR1V9uQwa9fhPC3OPbDXgFJZ86Hr\nL3Yjw6Ru0tW/Jy4jlzE4VD5RZwMnuWTxo9vWyafQ8S6+WTPWQcKamIfY6QzX\nM7hsGlT7eZ8GquFsoxw3NGjGDbGPAVUVi9CnipKqwbRwMrWplsBnmuLl4+nq\nXCUpVrrvg7q6HGPeqd1nS+TmNfz3qar7N+jhVzFwLsXncYgGUWdBncLMz6Oq\ndT5CUf2xfWxJ7z7uFddtlqN3I2+Th4Armw2mUueAdpDeWdegfdge+7tldsMk\nEVXb\r\n=c9Ab\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDeVCSi+hCzhtsYTIYuIfExAsJl+GuuCtXiN5o3vpVhGwIgEEdEVkFasYQixI/EldTEMhWqsXX6/BQdtNkvvHXvbJA="}]},"maintainers":[{"name":"buschtoens","email":"buschtoens@gmail.com"}],"_npmUser":{"name":"buschtoens","email":"buschtoens@gmail.com"},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/ember-engines_0.7.2-rc.1_1559045600535_0.18837920720304946"},"_hasShrinkwrap":false}},"time":{"created":"2019-01-09T13:49:47.651Z","0.5.26-beta.1":"2019-01-09T13:49:47.966Z","modified":"2022-04-04T21:08:42.273Z","0.5.26-beta.2":"2019-01-09T14:22:19.295Z","0.7.2-rc.1":"2019-05-28T12:13:20.695Z"},"maintainers":[{"name":"buschtoens","email":"buschtoens@gmail.com"}],"description":"Experimental support for Ember Engines","homepage":"https://github.com/ember-engines/ember-engines#readme","keywords":["ember-addon"],"repository":{"type":"git","url":"git+https://github.com/ember-engines/ember-engines.git"},"bugs":{"url":"https://github.com/ember-engines/ember-engines/issues"},"license":"MIT","readme":"","readmeFilename":""}