Then the controllers.js file only handles the routing controllers, and the html for each route is built solely out of components.

I resisted using require at first because it seemed like clunky cruft on top of Angular's cruftless dependency injection, but I was wrong and this way of working has been a lot of fun, relatively stress free and great for new devs since they just need to get their head around the way a component is put together and they never have to worry about other parts of the app.

The credit for this stuff has to go to a guy called Tim Kendrick whom I work with. He set up the project that my project is based on. He figured out the project structure and I've basically copied it with a few minor adjustments.

https://github.com/tnajdek/angular-requirejs-seed

You can structure the app however you want, but I would suggest having a component directory which is structured like this...

---------

src/js/components

|- myComponent

  |- myComponent.js  

  |- myComponent.html  

  |- _myComponent.scss

Then you need an extra module that you inject when you're defining your app. This module is responsible for injecting all the components you want to include, here's a Gist

https://gist.github.com/gargantuan/8902061

So every time you create a new component, you have to require it in components.js AND you have to include the sass partial in your main .scss file.

On the subject of sass, you'll need to prevent sass files being included more than once. Fortunately 'courtismas' has a solution for that

https://gist.github.com/courtsimas/1167053

Other notes:

I'm using Gulp for my build tasks. I can't recommend it enough. I'm looking into creating a Gulp task that will generate a JSON manifest of components so new components are automagically included in the app. That way there's no need to manually maintain the sass and components.js files.

http://www.startersquad.com/blog/angularjs-requirejs/

  if you select an element in DOM inspector in Chrome, 
  its scope will be accessible via $scope in the console

  angular.element(document).injector().get('myService')

I build based on features, with all the code and tests of a feature placed together, 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.

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...

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.

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.

[1] https://github.com/ngbp/ngbp#readme