Defining a partially typed Shape/Object

Is there a way to define only a "part" of the object type, while having the rest of it essentially be "any" type? The goal main goal here is to have intelliSense support for the part that is defeined, but if types-checking support is included, all the better. To illustrate, lets first define one helper type:

type TupleToIntersection<T extends any[]> = {
  [I in keyof T]: (x: T[I]) => void
}[number] extends (x: infer U) => void
  ? U
  : never

It does what the name implies, now let's deal with the issue

type A = {
  A: { name: "Foo" }
}
type B = {
  B: { name: "Bar" }
}
    
type Collection<T extends any[]> = TupleToIntersection<{ [I in keyof T]: T[I] }>

declare const C: Collection<[A, B]>

C.A.name // "Foo" as expected
C.B.name // "Bar" as expected

declare const D: Collection<[A, any]>

D // <=== this is now of any type because obviously an intersection of any and type A gives back any
D.A.name // <=== So whilst this is technically still okay, there is no "intelliSense" support

Any way to achieve this?

One idea I had was to keep the type as "any" and then have a typeguard to force it into a type that I know the shape of, where I am using it in code, which I think is the way that tsc actually wants to keep it as a "typesafe" code, but this requires "unnecessary" defning of a typeguard as well as defining types where you need to use them instead of having them defined "for you" by the system

The intersection is similar to the mathematical set intersection, where the result of A & B are all elements from A and B.

any is a set that contains every possible value so intersecting with any will give any at the end:

// any
type Case1 = number & any;
// any
type Case2 = {a: string} & any;

To fix it you can replace any with unknown, which is similar to any, however, the compiler will give preference to the type from the other set:

// number
type Case1 = number & unknown
// {a: string}
type Case2 = {a: string} & unknown;

Testing:

declare const D: Collection<[A, unknown]>;

D; // A
D.A.name // "Foo"

But if you want to support something extra to be added to the type, which I encourage you to avoid, you can use something more specific rather than any or unknown. For instance, to support adding new fields to an object one can use Record<string, any>

Testing:

declare const D: Collection<[A, Record<string, any>]>;

D; // A & Record<string, any
D.A.name; // "Foo"
D.additional = ''; // no error

Does this approach work for you?

/**
 * For some reason, TypeScript won't collapse string unions down to `string`
 * if they include it via `(string & {})`. This is a bit hacky, and I suspect
 * it may break in future versions of TypeScript.
 */
type StringWithAutocomplete<U extends string> = U | (string & {});

/**
 * This type defines your intellisense, excluding the catch-all `any` properties
 */
type BaseType = {
  A: number;
  B: string;
  C: boolean;
}

/**
 * For a given key, get its type in `BaseType` or otherwise resolve to `any`
 */
type KeyTypeOrAny<K extends StringWithAutocomplete<keyof BaseType>> =
  K extends keyof BaseType ?
    BaseType[K] :
    any;

/**
 * A mapped type that is functionally an intersection of `BaseType` and
 * `Record<string, any>`, but with type-checking on defined types and
 * intellisense.
 */
type AnyWithAutocomplete = {
  [key in StringWithAutocomplete<keyof BaseType>]: KeyTypeOrAny<key>;
};

const foo: AnyWithAutocomplete = {
  A: 3,
  B: 'string',
  C: true,
  D: 'undefined types can be anything'
};

TypeScript Playground

Just as an obligatory cautionary note, before I go into the details, be very careful with how you allow any to leak into your codebase. Any code that touches the any type is essentially opting out of TypeScript's type checking, so it's generally best avoided whenever possible.

As I've explained in the comments in the code example, this approach hinges on what I suspect is a rather hacky way in TypeScript to allow any string while retaining autocomplete.

Normally, any union of strings that includes string, for example 'A' | 'B' | string, collapses down to just string. However, if you change that union to 'A' | 'B' | (string & {}) then TypeScript will not collapse the union, so it retains the individual strings while also allowing any string.

The {} type includes everything except for null or undefined. Essentially, everything in JavaScript on which properties can be accessed without throwing an error - null and undefined are the only exceptions to that. The built-in utility NonNullable type is actually implemented using an intersection with this {} type, and this is also why it's typically warned against by linters since it may look like it just means "any object".

Anyway, I've used this quirk to create a mapped type that has some specific properties, while also allowing any string property. By defining a type which associates those named properties with a type, while falling back to any for other properties, this lets us create a type that is essentially an intersection between a well-defined object type and Record<string, any>, without causing TypeScript to collapse that intersection to simply any. This means you get to keep your type checking and autocomplete, but also have the open-ended type you were looking for.