Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to specify different folders for models and services #139

Open
matejchalk opened this issue Jun 22, 2023 · 0 comments
Open

Option to specify different folders for models and services #139

matejchalk opened this issue Jun 22, 2023 · 0 comments

Comments

@matejchalk
Copy link
Collaborator

matejchalk commented Jun 22, 2023

Proposal

Currently, it's only possible to generate all the models, services, etc. into the same folder using the -o/--output <path> option.

This proposal would be to add options to specify different target folders for API clients and interfaces. E.g. I could specify that models should go into libs/api-models/src/generated, while services would go into libs/api-clients/src/generated.

Motivation

The motivation is that it's a good practice to clearly separate interface from implementation (in this context, it means separating classes from non-runtime types). And sometimes the best way to achieve this separation is to represent it in the folder structure.

Real world example

My specific example is a large Nx monorepo, where we split the code into different libraries and enforce boundaries between them with Nx's tags and linting rule. Currently, all the API client code is generated into an api-sdk library, which we've tagged as type:data-access because it contains data layer logic. Other libraries are tagged as type:feature, type:ui or type:util (according to Nx recommendations), and our rules prevent type:ui or type:util libraries importing from type:data-access (to prevent mixing presentation and data layers).

The problem is that, because all the generated API code is in the same library, the same strict rule applies to both models and services. We want to prevent a presentational component from importing an API client. But we don't mind a presentational component importing an API model, because it's only a type definition. Because of the linting rule, we sometimes have to create artificial workarounds like creating duplicate types for the UI layer, which works fine for type-safety (assignments are checked structurally), because it feels like unnecessary boilerplate to maintain.

@vmasek vmasek moved this from To do to Planned in Main board Aug 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Planned
Development

No branches or pull requests

1 participant