Question: Limitations of client instance customisation

[Jokinen]

1. Can you confirm that the following pattern we attempted to use is out of scope for this project?
2. Could we achieve the same result ("dry") with some other approach?

What are the steps to reproduce this issue?

Setup a custom instance like so:

const createClientInstance = (config) => axios.create(config);
// Some details redacted in order to be concise
const createClient = (clientInstance) => (requestConfig, options) => clientInstance({
  ...requestConfig,
  ...options,
});

export const clientForService1 = createClient(createClientInstance({ baseURL: "***", timeout: 1000 }));
// ...
export const clientForService6 = createClient(createClientInstance({ baseURL: "***2", timeout: 2000 }));

We attempted to DRY the declarations here as we have multiple clients.

What happens?

Running the generate Orval CLI generator will result in a

Your mutator file doesn't have the clientForService1 exported function

Strictly speaking, this isn't necessarily true. A function of this name is in fact exported and it works when running the application. The issue is in how the function is declared. During generation, the script isn't able to determine the following variables numberOfParams and returnNumberOfParams when this kind of a factory pattern is used.

The processing of the AST result fails because parseFunction assumes there to be a body when in the above case the value is a CallExpression which doesn't have a body (link is to relevant line in the source).

The error is:

TypeError: Cannot read properties of undefined (reading 'type')

Caused by this line

if (declaration.init.body.type === "ArrowFunctionExpression") {

The error can be avoided like so:

export const clientForService1 = async (requestConfig, options) =>
  createClient(
    createClientInstance({ baseURL: "***", timeout: 1000 })
  )(requestConfig, options);

This pattern doesn't allow us to DRY up the declaration of the custom instances. It's not an insurmountable issue.

What were you expecting to happen?

I assume that the a factory pattern won't ever be supported as it would require too much processing of the AST result. But before understanding that the implementation relied on AST, it was easy to assume that any JS compatible implementation would work as long as it abided by the API that was advised in the documentation.

Something that could be worth consideration is to amend the documentation or the error message to more clearly communicate the supported patterns.

Alternatively it's possible that there's some other way to DRY up the code we are missing. In that case some sort of sample that allows DRYness when dealing with multiple custom clients could be interesting.