Making addon dummy apps less special

[ember-cli]

Making addon dummy apps less special

[ef4]

Based on what I described, it would necessarily be possible to add dependencies directly to the dummy app if you really want to. I'm not sure we'd want to rule that out -- maybe you need to test your addon both with and without another dependency present. But if you do that, you will need to run npm install in the dummy app.

Sticking to a subset of the main package.json and using * does seem like the sensible default behavior we should encourage.

[ef4]

I edited the main post above to add another bad case I had forgotten about:

Because the dummy app and the addon share a package.json, it's not possible to test what happens when an app depends on your addon but does not directly depend on your addon's own addon dependencies. In a dummy app, all the addon's dependencies are forced to be direct dependencies of the app too. For example, if you addon uses ember-cli-sass, you can't test what happens when your addon is used in an app that doesn't happen to also use ember-cli-sass.

[kellyselden]

The first point has a PR ember-cli/ember-cli#7602

[knownasilya]

Should these be split up and submitted as RFCs?

[lennyburdette]

dummy apps would become 100% normal ember apps. They should have their own package.json (like ./sample-app/package.json) ...

• Would this make developers think they can ember install or npm install --save-dev inside the ./sample-app directory?
• Would we want some validation to ensure that ./sample-app/package.json doesn't include any packages not in the addon's package.json? Or would something like ember-cli-dependency-checker handle that for us?
• Does it make sense to use * for versions in the sample-app's package.json to suggest that the sample-app inherits its dependencies from the addon?

  "devDependencies": {
    "ember-cli": "*",
    "ember-source": "*"
  }

Otherwise, 👍 ! I'm hoping that moving acceptance tests into the dummy app make engine tests easier. The sample-app application tests can run setApplication(), while the engine's rendering/container tests use setResolver(engineResolverFor(...)). Though I have no idea how that would work at runtime since setApplication and setResolver set global state ...

[bravo-kernel]

From an end-user perspective I would really welcome the ability to create multiple dummy/sample apps.

[ASH-Michael]

@bravo-kernel Isn't this already possible with routes in the dummy app?

From an end-user perspective I would really welcome the ability to create multiple dummy/sample apps.

[bravo-kernel]

Not completely separated as far as I know. I think I need something like https://github.com/mansona/testing-mu to get what I'm after; completely isolating ember-addon-docs and my demo-app. Update: but I'm pretty new to Ember so I could be mistaken.

[ASH-Michael]

@bravo-kernel I see what you are trying to accomplish now. Interesting.

[rwjblue]

We are working on closing the ember-cli/rfcs repo in favor of using a single central RFC's repo for everything. This was laid out in https://emberjs.github.io/rfcs/0300-rfc-process-update.html.

Sorry for the troubles, but would you mind reviewing to see if this is still something we need, and if so migrating this over to emberjs/rfcs?