Implementing Extensible Records in TypeScript

In many programming scenarios, you need to represent data structures that can have a fixed set of known properties, but also allow for arbitrary additional properties to be added. This is common when dealing with dynamic data, configuration objects, or when integrating with systems that might introduce new fields. This challenge focuses on building a robust and type-safe way to implement such "extensible records" in TypeScript.

Problem Description

Your task is to create a TypeScript type or utility that allows you to define a base record type with a specific set of required properties, and then extend it with additional, dynamically defined properties. The key is to maintain type safety throughout this process, ensuring that you can access both the base and the extended properties correctly, and that TypeScript can infer the resulting type accurately.

What needs to be achieved: You need to define a mechanism (likely a generic type or a combination of types) that takes a base record type and an extension type. The resulting type should represent a record that has all properties from the base type and all properties from the extension type.

Key requirements:

1. Type Safety: The extended type must be type-safe. Accessing properties from both the base and the extension should be correctly typed by TypeScript.
2. Extensibility: The solution should allow for arbitrary additional properties to be added to the base record.
3. Readability: The resulting types should be as readable as possible.
4. No Runtime Overhead (Ideal): The solution should leverage TypeScript's type system and aim for minimal to no runtime JavaScript overhead.

Expected behavior: Given a base type and an extension type (or an object representing the extension), the resulting type should combine them. If there are overlapping property names, the behavior should be consistent with TypeScript's intersection type merging (i.e., the more specific type or the type from the "later" part of the intersection often wins, or it can lead to a union if types are incompatible). For this challenge, assume that if a property exists in both the base and the extension, the type from the extension should be preferred.

Important edge cases to consider:

• What happens if the extension adds a property that already exists in the base? (As mentioned, extension takes precedence).
• What happens if the extension adds properties that are not explicitly defined in the base, but are part of a broader index signature?
• How does this interact with optional properties in the base?

Examples

Example 1: Basic Extension

// Base Record Type
type UserProfile = {
  id: number;
  username: string;
  isActive?: boolean; // Optional property
};

// Extension Object (or type representing extension)
const userSettings = {
  theme: 'dark',
  notificationsEnabled: true,
};

// Your implementation here to create an ExtendedUserProfile type
// type ExtendedUserProfile = ExtendRecord<UserProfile, typeof userSettings>;

// Expected usage and type inference:
// const user: ExtendedUserProfile = {
//   id: 123,
//   username: 'johndoe',
//   isActive: true,
//   theme: 'dark',
//   notificationsEnabled: true,
// };

// console.log(user.id); // Should be type number
// console.log(user.theme); // Should be type string
// console.log(user.isActive); // Should be type boolean | undefined

Expected Output (Conceptual, demonstrating type inference):

type ExtendedUserProfile = {
  id: number;
  username: string;
  isActive?: boolean | undefined;
  theme: string;
  notificationsEnabled: boolean;
};

Example 2: Extension with Overlapping Property

// Base Record Type
type ProductInfo = {
  name: string;
  price: number;
  description: string;
};

// Extension Object
const productDetails = {
  price: 19.99, // Overlapping property
  sku: 'XYZ789',
  weightKg: 0.5,
};

// Your implementation here to create an ExtendedProductInfo type
// type ExtendedProductInfo = ExtendRecord<ProductInfo, typeof productDetails>;

// Expected usage and type inference:
// const product: ExtendedProductInfo = {
//   name: 'Wireless Mouse',
//   price: 25.50, // This value would be used, and its type should be number
//   description: 'A comfortable wireless mouse',
//   sku: 'XYZ789',
//   weightKg: 0.5,
// };

// console.log(product.price); // Should be type number (and the value from productDetails is preferred)

Expected Output (Conceptual):

type ExtendedProductInfo = {
  name: string;
  description: string;
  price: number; // Type from the extension is preferred if it exists in both
  sku: string;
  weightKg: number;
};

Example 3: Extension with Index Signature

// Base Record Type
type Config = {
  appName: string;
  version: string;
};

// Extension Object with arbitrary properties
const environmentSpecificConfig = {
  apiUrl: 'https://api.example.com',
  debugMode: true,
  // Potentially many other properties
  [key: string]: any // This object could have arbitrary string keys
};

// Your implementation here to create an ExtendedConfig type
// type ExtendedConfig = ExtendRecord<Config, typeof environmentSpecificConfig>;

// Expected usage and type inference:
// const finalConfig: ExtendedConfig = {
//   appName: 'MyAwesomeApp',
//   version: '1.0.0',
//   apiUrl: 'https://api.example.com',
//   debugMode: true,
//   timeout: 5000, // This property wasn't explicitly in environmentSpecificConfig but is allowed
// };

// console.log(finalConfig.appName); // Should be string
// console.log(finalConfig.apiUrl); // Should be string
// console.log(finalConfig.timeout); // Should be inferable as number if handled correctly

Expected Output (Conceptual):

type ExtendedConfig = Config & {
  [K in keyof typeof environmentSpecificConfig]: (typeof environmentSpecificConfig)[K];
} & {
  // This part handles the index signature, allowing any string key with a specific value type if known, or 'any'
  [key: string]: string | boolean | number | undefined; // Adjust type as needed based on typical extension values
};

Constraints

• The solution must be written entirely in TypeScript.
• The solution should primarily focus on type-level manipulation, avoiding unnecessary runtime code.
• The implementation should be general enough to work with any valid TypeScript object types.

Notes

This challenge is about leveraging TypeScript's powerful type system, particularly generics, mapped types, and intersections. Consider how you can combine existing types to form a new, extended type. Think about the difference between using a type representing the extension versus an actual object value from which to infer the extension type. The keyof and typeof operators will be invaluable here. Pay close attention to how intersections handle property merging.