I like the idea of this package overall: reducing route-losing boilerplate and enforcing a convention are wins in my book. However I do have some notes and que

I like the idea of this package overall: reducing route-losing boilerplate and enforcing a convention are wins in my book. However I do have some notes and questions about the design. 1. In the structured example [0] (link to this is broken in the README, btw), filenames contain the directory name, which stutters: controllers/user/user.action.js. Why not either use index.js, or unprefixed names like action.js? 2. With file paths providing routes like this, one strength is that one can rename a route by moving files around. However, your example controller specs [1] have the route path hard-coded, including config like the Lumie prefix that a controller shouldn’t be concerned with at all. You should find a way to remove this inverted dependency. When I write express apps, I create a new app for each route, and then mount them all in the main app, so that no controller knows it’s own route, and controllers and routes are easy to relocate. You could do the same by expecting specs make their own call to Lumie.load with __dirname or something, to load just the controller they test at /. 3. You should provide an example of nested controllers routing, eg GET /users/:id/pets , /users/:id/pets/:id, as I’m unclear how to structure that with Lumie. [0]: https://github.com/Alex-Levacher/Lumie/tree/master/example/controllers/user https://github.com/Alex-Levacher/Lumie/tree/master/example/c... [1]: https://github.com/Alex-Levacher/Lumie/blob/master/example/controllers/user/user.spec.js https://github.com/Alex-Levacher/Lumie/blob/master/example/c...