Support for nested dir structure while using generators?

[jagzmz]

Suggestion

So, as of now, lb4 cli makes immediate files under models, controllers, repositories folders, maybe add a flag while running the generator something like --dirNested asks for the directory path and generates a file in that respective directory.

Use Cases

Some people might need to maintain a directory structure, instead of every file placed in the same dir.

Examples

lb4 controller --dirNested
> Name the directory in which you want to create the controller: UserControllers
> Name of the controller: user

lb4 controller --dirNested
> Name the directory in which you want to create the controller: UserControllers
> Name of the controller: userOrder

The file path for the above files would be like,

controllers/UserControllers/user.controller.ts
controllers/UserControllers/userOrder.controller.ts

If this looks useful, I might work on a PR for this.

Thanks.

[dhmlau]

I can see this being useful especially if an app have many models (for example) and can be grouped in subfolders. In order to support this, i believe we have to:
1/ make other generators be able to discover artifacts in their subfolders.
e.g. The repository generator needs to look for models in subdirectories

2/ make booters read the subfolders
e.g. https://loopback.io/doc/en/lb4/Booting-an-Application.html#booters. Not sure it reads subfolders by default.

@raymondfeng, what do you think about adding this capability?

[raymondfeng]

The runtime @loopback/boot already supports subdirectories under src/models. I'm not sure if we want to add one more prompt for the lb4 model command. Maybe make it conditional on presence of subdirectories.

Without this feature, we can still run lb4 model to generate model classes under src/models. Such classes can then be manually moved into corresponding subdirectories.

[dhmlau]

+1 on not putting it as part of the prompt, but was able to make LB artifacts inside the corresponding subdirectory discoverable.

[stale]

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

[stale]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.