Closed noslouch closed 8 years ago
sample implementation at ember-cli/ember-cli#4429
I agree that this raises a lot of questions about npm
.
I'm not sure the implications for ember-try
since npm
support in it doesn't fully exist yet.
I've often thought it would be nice to be able to link multiple sets of dependencies -- it would allow ember-cli
to provide an ember-cli-deps-package.json
and prevent developers from having to merge package.json
when upgrading, but in my mind that's always been a feature that would belong to npm
.
I'm not familiar with ember-try
, but I'll look into it.
The use-case that motivates this for me is another "parent app" has a combined set of dependencies for multiple apps, and that "parent app" is where a dev would run any install
commands.
I'm wondering if it's reasonable to expect that someone who uses this feature would be doing so after careful thought; meaning if I'm using this feature, it will be "top of mind" from which directory I should be running npm install
and ember install
and such.
@noslouch so the alternative to this, is to have multiple apps all with fleshed out package.json ?
@stefanpenner if I'm understanding you correctly, the answer is yes. the alternative to this proposal would mean each ember app has its own fleshed out package.json with its own distinct set of devDependencies
to be maintained.
I'm torn, i do see some value in this, but I am nervous to add extra complexity here to support an edge-case, which itself has some edge-cases.
One thought: I wonder if we could expose the right hooks/api, to enable this to be a user-land extension?
I think the right hooks would be fine. Is there already an established pattern for ember-cli
hooks? How would one use such an API?
Having said that, my sample implementation is already hook-ish, in that ember-cli
will operate as normal unless a special foreign dependencies key is present.
Unfortunately i don't feel comfortable adding this complexity. The combination of package.json + inherited package.json, and the existence of how the node resolution algorithm already works would create a rather complicated experience.
If this is demonstrated as a fleshed out stable, and semi popular addon we can re-evaluate it as part of the default offering.
That's fine. My use case eventually resolved itself by the old tried and true "just combine your apps" method
rendered output