Generated angular client module will always be called ApiModule.
The module also exposes a Configuration object which also cannot be renamed.
This isn't great when multiple generated clients are needed in a single project.
I'd like an Config Option for typescript-angular that can configure the Module and Configuration prefix.
Option | Description | Values | Default
-- | -- | -- | --
modulePrefix | The prefix of the file and class of the generated module (class <prefix>Module). | 聽 | Api
configuraionPrefix | The prefix of the file and class of the generated configuration object (class <prefix>Configuration). | 聽 | null
Note _the names are in the default fileNaming: camelCase format, but kebab-case should also be supported_
馃憤 Thanks for opening this issue!
馃彿 I have applied any labels matching special text in your issue.
The team will review the labels and make any necessary changes.
I agree on configurationPrefix, but why would modulePrefix be necessary?
It isn't useful to import the module anywhere if you use the providedInRoot option (https://openapi-generator.tech/docs/generators/typescript-angular)
As an alternative you can easily post process whatever gets generated, e.g. do renaming or replacements, transpile it to js, bundle it, etc.
I agree on
configurationPrefix, but why wouldmodulePrefixbe necessary?
It isn't useful to import the module anywhere if you use theprovidedInRootoption (https://openapi-generator.tech/docs/generators/typescript-angular)
You cannot use providedInRoot on modules only on services. So you import the api modules in the root module. But if you have multiple clients it'll look like this.
import {
ApiModule as FooApiModule,
Configuration as FooApiConfiguration
} from "src/generated-clients/foo";
import {
ApiModule as BarApiModule,
Configuration as BarApiConfiguration
} from "src/generated-clients/bar";
@NgModule({
imports: [
FooApiModule.forRoot(
() =>
new FooApiConfiguration({
basePath: environment.fooUrl
})
),
BarApiModule.forRoot(
() =>
new BarApiConfiguration({
basePath: environment.barUrl
})
)
]
})
export class AppModule {}
No need to import the modules if the services are providedInRoot. The configuration can be set via dependency injection
Oh yeah that's right. That make things a lot simpler. Or well in a way.
import {
ApiModule as FooApiModule,
Configuration as FooApiConfiguration
} from "src/generated-clients/foo";
import {
ApiModule as BarApiModule,
Configuration as BarApiConfiguration
} from "src/generated-clients/bar";
@NgModule({
imports: [
FooApiModule.forRoot(
() =>
new FooApiConfiguration({
basePath: environment.fooUrl
})
),
BarApiModule.forRoot(
() =>
new BarApiConfiguration({
basePath: environment.barUrl
})
)
]
})
export class AppModule {}
vs
import { Configuration as FooApiConfiguration } from "src/generated-clients/foo";
import { Configuration as BarApiConfiguration } from "src/generated-clients/bar";
@NgModule({
providers: [
{
provide: FooApiConfiguration,
useValue: new FooApiConfiguration({
basePath: environment.fooUrl
})
},
{
provide: BarApiConfiguration,
useValue: new BarApiConfiguration({
basePath: environment.barUrl
})
}
]
})
export class AppModule {}
It's not much different. So I still think that people should have the option to name their module and configuration then they can use the "style" they want.
BTW the BASE_PATH token should probably also be affected by configurationPrefix option.
export const BASE_PATH = new InjectionToken<string>('basePath');
Wont the 'basePath' have to be unique? So
```ts
export const PREFIX_BASE_PATH = new InjectionToken
````
Maybe a single option that affects all of the above would be the best approach.
basePath is just a description, it is the very reference to BASE_PATH which is unique, even if the expression
export const BASE_PATH = new InjectionToken<string>('basePath');
appears several times in the code
so I think we should close this issue, as there is little to no gain at the expense of more configuration options.
fair enough
@snebjorn there is a PR that allows configuration of the ApiModule name: https://github.com/OpenAPITools/openapi-generator/pull/4209
That's fantastic :)
Would you be open to a pull request for this one for configurationPrefix too?