Export the InferOptions and InferArguments type helpers

[nipunn1313]

This allows callers to write helper methods that manipulate commands (eg to add options to a preexisting command)

This is technically already possible if you rely on type inference, but I've run into:

error TS7056: The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.

Pull Request

Problem

It is not possible (I believe) to type methods like this

export function addMyCustomOptions<
  Args extends any[],
  Opts extends OptionValues
>(command: Command<Args, Opts>, action: string) {
  return command.option("--custom-thing");
}

If ts can infer the return type, things are fine, but sometimes it gives:
error TS7056: The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.

In this case, I believe we would need InferOptions which is private

Solution

Make InferOptions type exported.

ChangeLog

[nipunn1313]

I am open to other solutions. These exported types would work, but don't seem ideal.

[shadowspawn]

If ts can infer the return type, things are fine, but sometimes it gives:

error TS7056: The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.

Did you see this error on a branch where you had added this to the action handler?

We saw some similar problems in some different approaches to the type inference:

• Improve Command typings tj/commander.js#1758 (comment)
• Improve Command typings tj/commander.js#1758 (comment)

[nipunn1313]

It wasn't a this it was just a long chain of

export function addMyOptions<...>(command: Command<Args, Opts>) {
  command
    .addOption(new Option())
    .addOption(new Option())
    // .{about 5-7 of these, some including .conflicts()}
}

The output type of that function was not inferable - and tsc gave that error.

I actually found a workaround which was splitting the function into two halves and having all the callsites call both of the methods. The workaround kinda sucks. You can't write a helper to call the two helpers because it overloads tsc in this way.

[shadowspawn]

Somewhat related issue: #32

[nipunn1313]

yeah - perhaps there's some way to to reduce complexity on typescript via some kind of optimization to mitigate this.

I was running into it with just 5-7 options which feels... too quick.

Seems like typescript has some limit at 50 recursion depth https://github.com/bluepichu/ctf-challenges/blob/d83b02dffe2c7d2404c3fa0c27da886d61ff4c98/plaidctf-2020/thats_a_lot_of_fish/handout/tsc.js.diff

[shadowspawn]

I have not got my head around the issue yet. I found a mention of that error message with a fix from a Typescript guru but not sure if it is relevant. Posting for future reading!

• Broken inferred recursive types microsoft/TypeScript#43817

[shadowspawn]

Did you see this error on a branch where you had added this to the action handler?

That was a misguided question sorry. A few PR were opened in short time frame and I assumed they were all related!

[shadowspawn]

Have you got a reproduction? What version of Typescript? I am up to 20 options in a toy program and not had an error yet. I am interested in reproducing, and wondering whether it is a particular method call that is the problem, or basically just lots and lots of type inference.

function addMyOptions<Args extends any[] = [], Opts extends OptionValues = {}>(command: Command<Args, Opts>) {
    return command
        .addOption(new Option('-a, --aaa'))
        ...
        .addOption(new Option('--A <value>').preset('A').default('D'))
        ...
);

const program = new Command()
   .option('--port <number>', 'port number', parseFloat, 80)
   .argument('[rest...]');

const fullProgram = addMyOptions(program);

[nipunn1313]

I have a non-minimal repro in our codebase. Let me see if I can extract it.

[shadowspawn]

Was addMyOptions being included in a TypeScript definition file? I notice that the error in microsoft/TypeScript#43817 only occurs when generating a definition file.

[shadowspawn]

It is technically easy to export more types, but I don't want to do so without understanding the problem it is solving. I will close this for now, but if you want to keep working on this @nipunn1313 then I can reopen.

Feel free to open a new issue if it comes up again, with new information and renewed interest.

Thank you for your contributions.