`Router.navTo`'s `oComponentTargetInfo` parameter has incorrect key type

[DetachHead]

export default class Router extends EventProvider {
    navTo(
      sName: string,
      oParameters?: object,
      oComponentTargetInfo?: {
        anyName?: {
          route?: string;
          parameters?: object;
          componentTargetInfo?: object;
        };
      },
      bReplace?: boolean
    ): this;
}

anyName means that typescript will enforce that the key is literally called anyName. instead it should be something like

oComponentTargetInfo?: {
    [anyName: string]: {
      route?: string;
      parameters?: object;
      componentTargetInfo?: object
    }
}

though that means you can have multiple objects in oComponentTargetInfo, for example:

router.navTo('foo', {}, {name1: {/*.../*}, name2: {/*.../*}})

is that valid? if not, you could make it so only one key is allowed, like so:

type UnionToIntersection<U> =
    (U extends any ? (k: U) => void : never) extends ((k: infer I) => void) ? I : never

type OnlyOne<T extends string> = string extends T ? never :
    UnionToIntersection<T extends any ? () => T : never> extends () => (infer R) ? (() => T) extends (() => R) ? T : never : never

declare class Router {
    navTo<TargetName extends string = never>(
        sName: string,
        oParameters?: object,
        oComponentTargetInfo?: OnlyOne<TargetName> extends never ? never : {
            [anyName in TargetName]: {
                route?: string;
                parameters?: object;
                componentTargetInfo?: object;
            };
        },
        bReplace?: boolean
    ): this
}

• playground link
• stackoverflow post with more info on how it works (ignore the part where he says to never do this, as that's not relevant because we have no need to preserve the order of the union. all we're doing here is prohibiting unions entirely)

[akudev]

Hi, thanks for your report. Yes, that's wrong. And regardless of where you encountered it, it's also an issue in the recommended ts-types-esm definitions. Thanks also for your solution suggestion, but as the type definitions are generated, we'd rather need to check how such a thing is described in JSDoc and how we get the correct solution generated.