> with any shared dependencies lower down in the directory structure

Heh, I'm just imagining code bubble up :P

Though that's definitely a wrong way to think of it since it's a call tree, but it always bugged me that in JS, you'd have to download dependency code you might not use (hence important code "bubbles up"). That's why I'm intrigued to try Dart for it's "tree-shaking" compiler that removes unused code from dependent libraries.

> The 'controllers/directives/services' grouping is straight up moronic

I tend to agree, and this is how I'd organize a larger Angular app, but to be honest I don't think it makes a huge impact in the long run. Rails apps are divided into dirs for models/controllers/views/etc and while I would rather have them organized by feature, they're still easy enough to navigate with modern code editing tools. It's certainly not one of the main contributing factors to how horrible big Rails apps get...

I do it both ways. Major features I pull out into a features folder, but the main skeleton of the app I keep in monolithic controller/directive/services files (or folders if necessary). It encourages me to keep my controllers skinny while providing a place for shared logic to live. It's a good compromise.

I missed out a part of what I do - in order to properly encapsulate and test functionalities within services, they are built out of smaller services that I can test individually, and these get their own directory folders and trees, so long as they are dependencies of an individual service.

What do you do for directives that are shared across your whole app?

I agree with WalterSear that organizing by feature is best. For things that are shared, I like to have a shared/util directory for the miscellania, grouped by purpose (as needed). So, say, if you end up with a few directives used for form validation, you might end up with a util/validation directory somewhere.

The most important question is "can I quickly guess what directory this directory lives in?"

When you come across directives that clearly feel "utility", you will be tempted to look in a utility folder. When a directive is something tightly coupled to a feature, you might be tempted to first look in the directory related to that feature.

Since they won't be used by the main application (ie - app.js, routing, etc, etc), just by features, they bubble up to the root 'features' directory that is contained in the scripts directory.

I forgot to add, I will also create a directory tree for singular service dependencies, so that a service can have multiple, non-shared, dependencies that are each considered a 'feature' and consequently have their own folder containing their code and tests.

I need to blog this, but node is fighting with osX on my macbook right now. I am not a happy camper.