Add option for orverriding placement of files generated with CLI generators

[jwoertink]

Currently if you use lucky gen.model this will put the file in src/models/ however, some people prefer to structure their apps in a different manner.

I haven't confirmed this, but I'm told that Marten offers a CLI flag of --app or --module that will place the files in to alternate structures. I'm not sure what that looks like exactly, but when this came up in Discord, here's an example structure for a Lucky app

On the one hand, having an option like --module that would automatically structure the generated files like this would be nice, but on the other hand, if you're looking to structure your app differently and it's not like this or the default, then you're still left with not being able to use the CLI generators and hand moving all of your files around...

Lucky should always try to provide an escape hatch for when some design choice was made and someone wants a way around it. I think maybe just adding a --dir=./src/path/to/where you want might be good. Though, I'm not sure how using lucky gen.resource.browser would work since this creates files in like 6 different spots. Now we're talking about 6 new flags??

lucky gen.resource.browser Post title:String --model-dir=./src/modules/blog/ --migration-dir --operation-dir --query-dir --actions-dir --pages-dir

We had some discussion about this before https://github.com/luckyframework/lucky/discussions/642

So I guess this comes down to 3 options:

• Lucky doesn't support alternate structures, and if you want to use something different, then it's up to you to hand-roll for each project
• Lucky supports very specific structures that are A, B, or C, and that's it. If you don't like those options, you're still left with hand rolling. This option would also make testing app generation O(n) times more difficult ref
• Lucky adds CLI flag options for each file location allowing you to specify. This makes CLI use extremely difficult and verbose and prone to lots of mistakes as a typo could be missed e.g. --mirations-dir.

[ExtroBeats]

Thank you for the response! Here are a few additional thoughts from me:

• How it works in the Marten Framework - Link
• In my opinion, in the eternal debate of customizability vs. conventionality, there cannot be an extreme position - the right choice is always some rational compromise. Many of us have come to Crystal from the world of Ruby with its Ruby on Rails and the paradigm of Convention over Configuration. I, probably like many others, tend to lean more towards conventionality by default. Therefore, the third option seems incredibly excessive to me.
• The question of whether to split the project into independent modules or not is an important architectural decision that affects the quality characteristics of the project. For example, it can affect the ability to relatively easily extract something into a separate service/microservice. And the folder structure only affects the ease of use. It seems to me that this also points to the optimal compromise between configurability and standardization. For me, it seems quite normal to make the first one (modularity) optional, and the second one (internal folder structure of modules) fixed at the level of convention. That is, in general, I'm in favor of approximately how it's done in the Marten Framework.

[jwoertink]

I'm still having trouble seeing this conceptually. So would this just keep the same structure, but drop it all in to a sub-module namespace?

lucky init
# enter wizard
Use Module structure? Y
App name: blog

generated files
src/blog/actions
src/blog/models
src/blog/queries
src/blog/serializers
src/blog/pages

lucky gen.model User --module=blog
src/blog/models/user.cr

----------------------------

lucky init
# enter wizard
Use Module structure? N
App name: blog

generated files
src/actions
src/models
src/queries
src/serializers
src/pages

lucky gen.model User
src/models/user.cr

So is this what the flow would look like? In this case we're just saying that everything is either within a namespace or not. That might make it easier to manage from implementation.

[ExtroBeats]

So is this what the flow would look like? In this case we're just saying that everything is either within a namespace or not. That might make it easier to manage from implementation.

Yep. That is exactly how it could look like (at least to my taste).