Ability to declare components as dependencies about ember-engines HOT 27 OPEN

ok, the above works if I reexport the component in my engine: export {default} from 'in-repo-oam/components/call-to-book-content/component';

from ember-engines.

The only (big) problem I have left is that I can not create an in-repo addon inside the dummy app of my engine. So can't test the above :(

First I had to add explicittly the Mirage path in my engine's index.js to manage to start serving the dummy app:

module.exports = function(defaults) {
  let app = new EmberAddon(defaults, {
    // ..
    'ember-cli-mirage': { //https://github.com/samselikoff/ember-cli-mirage/issues/524#issuecomment-177632450
      directory: path.resolve(__dirname, path.join('tests', 'dummy', 'mirage'))
    }
  });

Then I'm able to start the dummy app, but the registry doesn't have the path to my component: in-repo-oam/components/call-to-book-content/component

I tried to add component files in a root in-repo-oam folder, and mess with the treeForApp hook in the `index.js of my engine, to add the folder in the registry:

//index.js
const EngineAddon = require('ember-engines/lib/engine-addon'),
  path = require('path'),
  MergeTrees = require('broccoli-merge-trees'), 
  Funnel = require('broccoli-funnel');// add 'broccoli-funnel' in your dev dependencies

module.exports = EngineAddon.extend({
  //..
  treeForApp(appTree) {
    let trees = [appTree];
    if (this._shouldIncludeInRepoOamMock()) {//only in dev and test
      let InRepoOamMockFolderName = '/in-repo-oam',
        isDummyApp = this.app.name === 'dummy';
      if (isDummyApp) {
        trees.push(new Funnel(path.join(this.root, 'tests', 'dummy', 'in-repo-oam'), {
          destDir: InRepoOamMockFolderName
        }));
      }
    }
    return new MergeTrees(trees, {
      overwrite: true
    });
  },
  _shouldIncludeInRepoOamMock() {
    return this.app.env !== 'production';
  }
});

It adds the files in the registry, but under the path: dummy/in-repo-oam/components/call-to-book-content/component instead of in-repo-oam/components/call-to-book-content/component

Stopping there, but it's a shame because I'm close.

from ember-engines.

@dgeb: I think @villander meant to ping you instead of me:

@stefanpenner @dbeg can you add this as 1.0 label. It’s super critical

from ember-engines.

The current recommendation (although alternatives are plausible) is to then extract that component as an addon. This is the level of composition the ensures dependencies of shared components are enumerated and compatible version ranges are declared. Now an invalid composition becomes a build time error, catching issues early. a potential future, were we allow multiple versions of the same component to exist is then plausible and could facilitate rolling upgrades

I believe anything more granular risks mitigating the engine value propositions.

from ember-engines.

I like @stefanpenner's thoughts on this. I could see extracting shared components that can be used by the CMS and the addons. Those components could communicate with the CMS via a service if need be, or they could just be UI elements that addons can use.

from ember-engines.

We had considered extracting the core set of components out into separate add-ons previously but decided against the idea after further thought.

Pulling components from the parent application would allow us to make changes to components (whether it be style, bug fixes or additional functionality), and have those changes flow through to the rest of the admin panel (add-ons included) without add-on authors being required to make any alterations for non-breaking changes.

Furthermore, requiring add-on authors to update their add-ons dependencies in order to pull in changes that we'd made, would eventually lead to multiple versions of the same component being used in different areas of the admin panel. This may then potentially lead to a feature having multiple UI's depending on which add-on or area of the admin panel was being used. Pulling the components from the parent application would ensure that the UI would remain consistent throughout the entire admin panel.

While we can see that exporting the components into separate add-ons would work and is a viable option in some circumstances, we believe that for our use case, it would create too much unnecessary work for not only add-on authors who would need to keep updating their add-ons dependencies, but also end users who would also need to keep updating their add-ons in order to have the changes that we'd made filter down into their admin panels.

We believe that this could also be the case for any other distributed projects attempting to create an add-on ecosystem.

from ember-engines.

this will need to be an independent RFC

from ember-engines.

Pulling components from the parent application ... and have those changes flow through ... without add-on authors being required to make any alterations for non-breaking changes.

would ^x.y.z in your package.json do the trick for this part?

from ember-engines.

would ^x.y.z in your package.json do the trick for this part?

Unfortunately not as this would still require add-on authors to re-build the engine and re-package their add-on whenever we released a new version of a component. Users of the CMS would then also need to update the version of the add-on being used.

from ember-engines.

I wouldn't mind taking a stab at drafting an RFC for this if someone else wouldn't mind reviewing it before submission.

Does anyone have any other particular points/concerns that they would like to be addressed/explored in the RFC?

@dgeb / @rwjblue - Do either of you guys have any thoughts or concerns?

from ember-engines.

It seems as though in-repo-addons being used for both shared components and engines does not work, as the engine does not include the component addon as a dependency.

Example of what I'm trying to do:

{
  "name": "fs-group-engine",
  "keywords": [
    "ember-addon"
  ],
  "dependencies": {
    "ember-hammertime": "1.0.2",
    "ember-cli-babel": "^5.1.6",
    "ember-cli-htmlbars": "^1.0.3",
    "flexi": "^1.1.7"
  },
  "ember-addon": {
    "paths": [
      "./ember-scoped-action-helper",
      "./shared-materials"
    ]
  }
}

from ember-engines.

Can somebody enumerate why this is hard?

from ember-engines.

@devinus It's not necessarily difficult, a decision just needs to be made whether to allow this functionality or not. I'm hoping to publish an RFC in the next week or so proposing that this functionality be added.

from ember-engines.

I mean, being able to share components is huge. Not sure why that wouldn't be an eventual goal? Is there a reason it's a bad idea?

from ember-engines.

@devinus I agree but I think there are concerns that the more things we allow to become dependencies, the more we begin to break down the boundaries created by engines.

Currently the recommended approach to share components across applications/engines is to extract it as an add-on, though as @runspired mentions above, this approach does have its issues.

from ember-engines.

I'm creating engines as in-repo-addons. I'm sharing a single codebase for multiple engines, and it's honestly amazing. Shared store, shared session, shared CSS... I want to share more things. :)

from ember-engines.

Archiving this conversation on Slack with @nathanhammond and @cibernox for future reading.

cibernox: I think it's very common to have, say, ember-wormhole in your app
and it's used in several places (edited)
so you want to install it once in the main app and pass it to every engine
like services

mike183: Or even components that you build yourself that you plan to use throughout the whole application, an HTML editor for example.

nathanhammond: That one sounds like a non-routable engine.
(That distinction is something that we need to nail down as well.)

mike183: Being a route-less engine would still give me the same issue as moving the components into an add-on. It would also have the issue where data can't currently be passed into route-less engines from the template.

Say for example we updated the HTML editor to use Froala under the hood instead of Redactor, the engine authors would all need to update their engines to use the new version of the HTML editor engine.

Alternatively, if we were able to share components from the parent app into the engines, we would be able to make these changes and have the changes instantly take affect in all engines without requiring the authors of the engines (who would be third party developers) to release new versions of their engines.

Component dependencies would give us far more control over our applications UI/UX, using route-less engines or bundling shared components into add-ons would lead to a future where our > applications UI/UX became inconsistent and confusing.

from ember-engines.

I'm really not sure this thread is the best place for this, but there's a lot of relevant discussion so I'm plunking it here instead of opening a new thread.

The app I've been working on is technically a perfect candidate for ember-engines (a single platform with a series of "sub-applications" -- a great fit for lazy-loading), but the inability to share components without addon-izing everything is really throwing a wrench into the gears. It's a decent bit of effort to split this stuff apart (the app's about a year old so there's quite a bit of stuff), and a lot of the components wouldn't even make sense outside of this particular app (i.e. the addon would only ever be used for this one app, and that's it).

Piggybacking on @runspired's comment a bit, I'm trying to figure out if in-repo addons are usable from engines; seems like a reasonable compromise if so. This SO post seems to suggest it's possible, but it's a self-answer with zero votes or comments so I'm grain-of-salting the results for now. Either way, I'd quite like to avoid splitting stuff into a second repo.

I do understand the arguments supporting addon-ization (is this a word now?), but adoption is gonna be a lot tougher than I'd like. I may spin up a test app to tinker a bit with the in-repo thing; just figured it was worth tossing a question into the aether in case one of the proper experts has any advice on this.

from ember-engines.

@XaserAcheron in repo addons are usable from engines using local paths in package.json files.
there's been occasional chatter on the #ember-engines slack channel as to improving the documentation around this.

from ember-engines.

That'd help a bunch, I think. The assurance that it's a well-supported (if sparsely-documented) feature gives me enough clearance to tinker.

In-repo addons are an oddly well-kept secret in general, I'm finding. There's not a whole lot of information about them (in writing; there's that one video presentation but some goofballs like myself never find time for videos). Not that they're complex -- just a bit odd there's not a proper section in the ember-cli docs about them. Yet? :P

from ember-engines.

For posterity's sake (and for anyone else who lands on this issue after some Googlin'), in-repo addons & engines indeed play nicely together.

Here's my engine's (slightly-anonymized) package.json; hopefully the names of things are self-explanatory ;)

{
  "name": "plumbus-engine",
  "keywords": [
    "ember-addon",
    "ember-engine"
  ],
  "dependencies": {
    "ember-cli-htmlbars": "*"
  },
  "ember-addon": {
    "paths": [
      "../plumbus-addon"
    ]
  }
}

from ember-engines.

Here's a great video by Jacob Bixby explaining Ember-cli In-Repo Addons with a lot of background information on when (and how) to use them.

from ember-engines.

Heh -- the fact that I could only ever find links to that video, rather than any docs in writing, are what drew me to this GitHub issue in the first place. Full circles are the best circles. :P

from ember-engines.

Indeed, works like a charm and all makes sense now. Thank you all for chipping in.

from ember-engines.

@alexander-alvarez can you precise what you mean by "using local paths" ?

Trying to use an app in-repo addon from a lazy-loaded, not in-repo engine, with the following:

  "ember-addon": {
    "configPath": "tests/dummy/config",
    "paths": [
      "../in-repo-oam"
    ]
  }

And it's not working

from ember-engines.

@stefanpenner @dgeb can you add this as 1.0 label. It’s super critical

from ember-engines.

sorry @dbeg, I mentioned you wrong haha

from ember-engines.