Ember App Kit (EAK) with multiple apps

I saw @mixonic mention in his EAK article that he modified it to work with more than one app in the repo. I’m looking for some feedback on the best way to go about having more than one app, and having some shared/common resources that can be optionally imported into each app.

It appears that EAK blindly concatenates all files together, and doesn’t consider the actual import dependencies when deciding what to include in the build. The requirejs optimizer, for example, can combine files based on the actual dependency tree, which seems valuable so that you only build explicit dependencies into your files. That becomes particularly useful when certain modules require a shared resource, instead of the app (index.html) needing to know which shared resources each of the modules need, it will be built in based on the fact that the module imported it.

I’m admittedly new to Ember App Kit, so let me know if what I’m saying doesn’t seem to make sense, or goes against the philosophy. @mixonic, do you have an example of your multi-app EAK repo? Anyone else deal with similar issues?

2 Likes

EAK moves really fast. The specifics of what I did to run two apps in that codebase really wouldn’t apply to a current one.

But basically, you need to duplicate the app.js build pipeline to have a second file anotherApp.js built based on a second directory. Really, this is just hacking the grunt scripts. There is no formal support for multiple apps.

The tasks/ directory is the best place to start!

1 Like

The way we have it is two separate apps in different directories. We haven’t quite got around to organising the shared code but I imagine we will use a bower dependency, either pointing to a third directory or a git repo. See javascript - How to register a local git package in Bower? - Stack Overflow .

Our use case is two distinct apps though which share models, utility code and some views. If you have more overlap then perhaps mixonics solution would be more appropriate.

Can you provide the reference to the @mixonic’s article?

@beku8 the article I referenced.

@JRHE We are attempting to do something very similar. In our case, though, there are more than 2 apps, and each app optionally includes certain shared resources (views, models, mixins, etc).

Unfortunately, I think the trickiest part, besides the grunt task overhaul, is the shared resource management. Like I mentioned in my first post, EAK does not intelligently create the build. A primary purpose of modules (AMD, ES6, etc) is dependency management, and the fact that it has no bearing on actually building in those dependencies seems like a missed opportunity to say the least. @stefan, any thoughts on this?

I may look into modifying the build process to trace the dependency tree when building the app, unless @stefan thinks it’s a bad idea :smile:

Would love to hear what other people have done here. I’ve tried going down this path before, but it became very messy very quickly.