orval vs kubb

[nimo23]

I want orval to create files for fetch and client and therefore I have two Configs - I don't know if this is the right approach:

export default defineConfig({
	fetch: {
		output: {
			target: './src/api-orval/fetch/FetchApi.ts',
			client: 'fetch',
			httpClient: 'fetch',
			schemas: './src/api-orval/type',
			clean: true,
			prettier: true,
			namingConvention: 'PascalCase',
			mode: 'single',
			mock: false,
			override: {
				useDates: true,
				useBigInt: true,
				useTypeOverInterfaces: false,
				useNativeEnums: true,
				query: {
					useQuery: true,
				},
			}
		},
		input: {
			target: './openapi.yaml',
		},
	},
	reactQuery: {
		output: {
			target: './src/api-orval/query/ReactQueryApi.ts',
			client: 'react-query',
			httpClient: 'fetch',
			schemas: './src/api-orval/type',
			clean: true,
			prettier: true,
			namingConvention: 'PascalCase',
			mode: 'single',
			mock: false,
			override: {
				useDates: true,
				useBigInt: true,
				useTypeOverInterfaces: false,
				useNativeEnums: true,
				query: {
					useQuery: true,
				},
			}
		},
		input: {
			target: './openapi.yaml',
		},
	},
});

This generic Config approach has some disadvantages:

• I have two schemas properties. I should probably only keep the first one, since inserting schemas-properties later would unnecessarily recreate it, right?
• Setting some properties for a client doesn't make sense. For example, the combination client: 'fetch', httpClient: 'fetch' would be redundant.
• We don't have the option to make global settings. For example, the input-property could be defined globally

I'm comparing Orval with https://github.com/kubb-labs/kubb. Kubb allows for global configurations and dedicated configurations for each output (plugin architecture).

For example, in kubb, I do the following:

export default defineConfig(() => {
	return {
               // global properties used also for each plugin
		root: '.',
		input: {
			path: './openapi.yaml',
		},
		output: {
			path: './src/api',
			clean: true,
			defaultBanner: 'full'
		},
		plugins: [
			pluginTs({
				output: {
					path: './type'
				},
				group: {
					type: 'tag',
					name: ({ group }) => `${group}`
				},
				syntaxType: 'interface',
				enumType: "enum",
				dateType: 'date',
				unknownType: 'unknown',
			}),
			pluginClient({
				output: {
					path: './fetch'
				},
				group: {
					type: 'tag',
					name: ({ group }) => `${group}`
				},
				client: 'fetch',
				//baseURL: '.',
				operations: true,
				paramsType: "inline",
				pathParamsType: "inline",
				dataReturnType: 'full',
			}),
			pluginZod({
				output: {
					path: './validator'
				},
				group: {
					type: 'tag',
					name: ({ group }) => `${group}`
				},
				typed: true,
				dateType: 'date',
				unknownType: 'unknown',
			})
		],
	}
})

The questions:

1. In my orval.config.ts (from above), I have two schemas properties. I should probably only keep the first one, since inserting schemas-properties later would unnecessarily recreate it, right?
2. Would it make sense to redesign Orval to also have such a plugin architecture instead of a god configuration-object for each client? What are the advantages and disadvantages?