I use require.js for this. There are a number of seed projects out there to get you started, but I suggest not following them too closely. Once you understand the basic technique it's easier to figure out your own organizational structure. My main suggestion is to discard the seed project's suggestions of organizing things into directories like /controllers, etc., in favor of organizing the files around specific screens. This reduces friction when it comes to using things like route resolves, which are a huge pain if you have the routes in a routes.js and the controllers in controllers/MyController.js.
Thanks -- I had tried going down the requirejs route with all controllers loaded into a 'controllers' module, directives into a 'directives' module, etc., and felt like I was writing way more boilerplate code than should be necessary with a framework like Angular. I'll have to revisit using requirejs with more of a page/functionality-oriented structure.
Yeah, I don't get that approach at all. I started with that, ran into a case where I wanted a route resolve, couldn't figure out how to do it without a huge amount of hassle, and ended up reorganizing around screens. I do still have global services, directives, and filters, but I define them as close to screens as I can and only pull them up to a global scope when necessary. The module-per-screen approach makes a lot of sense from both Angular and Require's perspective, I think.
We use the optimizer as well, during our build process, so you can use require to load everything during development and then optimize everything down into a single file later. The optimizer is pretty powerful and supports several different scenarios for doing this.
Dont use requirejs,it solves very little problems. Have a dev distrib where you pile up js files and templates, and a prod distrib where your files are "merged" into one.
Requirejs is a nightmare to use, especially with the angularjs ioc container. Remember you can reopen the same module in different files.
