This is how I traditionally organized my files. However, I found that with large applications it really becomes painful to keep everything organized, unambiguously, etc. The “new” way I did it was to organize my files by function, not by type. So for example:
js/feature1/someView.js js/feature1/someController.js js/feature1/someTemplate.html js/feature1/someModel.js
But often there are global “things” that you need, such as a “user” or a set of places that a user has created. So:
js/application/model/user.js js/application/collection/location.js
This model was proposed to me, because then you can work with sets of functions, package them and deploy them using requirejs with relatively little effort. It also reduces the likelihood of dependencies between feature sets, so if you want to delete a function or update it with a new code, you can simply replace the stuff folder instead of searching for each file. In addition, in the IDE, it simply makes it easier to find the files you work with.
My two cents.
Edit: what about spec files?
A few thoughts - you just need to choose the one that seems most natural to you, I think.
- You can follow the same "function" pattern template with specification files. The good news is that all the specifications are in one place. The downside is that now, like what you are doing now, you have to place files for one file.
- You can put the specifications in the "spec" folder in the function folder. The good news is that now you have the actual packages that you can wrap in one ZIP file without any chance of knocking down another job. It is also easier to find directly related files for writing tests - they are all in the same parent folder. The disadvantage is that now your production code and test code are in the same folder, publishing it (possibly) in the world. Of course, you're likely to finish compiling javascript into a single file at some point .. so I'm not sure if most of the problem.
- My suggestion is if this is a large application, and you think you will have several hands touching files, leave something like a package.json / yml / xml file in the folder. It lists production data, specifications and any data files that you need for testing (for this, you can most likely write an operational shell script). Then run a quick script to browse the source folder for the “package.whateverYouChose” files, get the test files, and then create a device test page with it. So, let's say you add another package .. run 'updateSpecRunner' or something that you will call a script and it will generate another SpecRunner.html file for you (or whatever you called the file on which the specifications are running). You can then manually test it in a browser or automate it with phantomjs / rhino.
It makes sense?