ultimately, because of how elixir modules don’t care about file location, elixir projects are extremely easy to re-organize. took me 2 hours to totally reorganize our project. So, just do whatever you like and if you realize later you want to do it another way, its super easy to change.
atomkirk
Eiji
This is really interesting … I may like this way … From your project structure I see that you are not using contexts, right? What’s with modules implementing shared functionality for multiple features? It could be a huge mess with a really big number of schemas, isn’t it?
However …
I don’t like putting tests in same directory. All of the modules in lib would be unexpectedly used in some cases like:
- project documentation (
@moduledoc falsefor all tests
) - API of
hexlibrary (if not then it means you have 2 standards: one for apps and one for libraries which does not makes sense for me) - releases (if I remember correctly)
Also where is your test/support directory in such structure?
0
cvh23
cvh23
hlx
atomkirk
we renamed modules over time to match path, like Project.Payment (for project payment/schema.ex) or Project.Payments.Controller , but weren’t aggressive about it because it was really emotional more than practical. It FEELS good to have them match, but we rarely actually experienced a practical advantage. The only advantage I can think of is helping you find the file that contains the definition of a module when you are looking at the module being used. When I am looking for the file of a module, I just search for defmodule ModuleName and project search takes me right there. Or, more recently, most IDES with elixir language server have “go to definition”.
I agree though, if its not a big deal, its generally nice to have them match.
0
atomkirk
we did start moving to contexts with phoenix 1.4 come out and put them in payments/context.ex
so we had a shared directory that had child resources that had no clear home. so maybe shared/cloud_files/schema.ex (and others like context.ex). Cloud files being an abstraction of files stored on s3 or something. A lot of places in the app may use uploaded files.
So with tests, it works better than you may assume. None of those concerns you pointed out end up being a concern. I really think you should give it a shot and see.
we do still have a test directory that holds all the test support stuff (like test/support and fixtures, factories, etc)
If you only include your tests in lib and modify your mix.exs like this: test_paths: ["test", "lib"], because they are _test.exs files, they are ignored and not compiled into builds or releases.
2
Eiji
Ah, I see … When I was asking I had in mind splitting project into reasonable parts (each in its own directory). For example lib/accounts/user/schema.ex, lib/accounts/role/schema.ex etc. In really big projects there are dozens (if not more) of ecto schemas, so it would be a small pain to scroll them to find the right one.
Following this article:
By default whole lib directory is send to hex. Do you have some pattern for files option to only include .ex files inside lib directory (asking as never saw it in practice)? I saw one pattern somewhere, but not sure if it works in this use case. I guess it was something like "lib/**/*.ex", right?
Oh, I expected that you would put fixtures and factories in lib directory as well. 
Yes, I mean exactly this! As said I was not sure if they would be compiled or not. Now it makes more sense. Does ex_doc works in same way (i.e. only for .ex files)?
The more I read about it the more I’m interested!
It would be really helpful if you would provide all generic changes you made (like modification of mentioned by you test_paths). While I may sometime give it a try and slowly look for solutions/workarounds (for now I don’t have that much time) newbies may be confused seeing errors, so it’s important to properly describe needed changes. Maybe a blog post, small template or at least a name of such structure concept (like searching for Elixir Phoenix contexts in Google).
Also i have one more question … Did you had any problem with code analysis tools like credo. dialyzer or excoveralls? If so how did you solved them?
1
atomkirk
yep, we did exactly this 
I kept my example simple but we grouped mutliple resources into folder when it made sense. Your example was verbatum what we did An accounts folder with users folders, auth folder etc.
I think you might have me here… I’m not sure how to make it work with hex. Your idea suggests there could be a way to make it work without too much trouble?
test_paths is literally the only change we made… other than that we just started putting _test.exs files next to the module they test and everything works exactly like it did before.
Nope, all of those tools work as expected without any special config/hacking.
I’ve worked on a lot of projects where tests are in a root test directory and without exception I’ve had headaches looking for the test that tests the code I’m looking at. It helps a lot when they maintain a proper directory structure that mirrors lib, but I hate maintaining that personally and no one does it perfectly. Often what I have to do is IO.inspect and then run the whole test suite to see what tests exercise the code in question.
1
Eiji
Just tried it on newly generated project and unfortunately even with some tricks with Path.expand/1 for generating a raw list of directories and files it would end up including _test.exs files anyway as when we pass dir_name to files option whole directory is included. The only workaround I can see for it is to only provide a list of files without directories, but never tried it.
I don’t like to have 2 standards for organizing code (one for app and one for lib), so I’m gonna still have tests in test directory. Also keeping support and all test specific files in test directory when all tests are in lib looks like a workaround for me. If there would be an easy way to merge lib and test directories I may consider give it a try again.
Anyway I believe that grouping everything (except tests) into features is still reasonable for me, so I would definitely consider it in my future projects.
1