Feature request: #[TypeScriptPick] attribute to generate Pick utility types from DTOs

[valentin-morice]

Hi 👋

First of all I want to thank you for all the wonderful packages you're producing, my company and I use them every day. They even sent the you the postcard! This is my first feature proposal, and I think it's small enough to make it in the core. If you do not find it suitable, I can still release it as a package.

Problem

When using Laravel Data objects (or any DTO) with TypeScript, it's common to return partial representations from API endpoints. For example, a UserData class might have 15 properties, but a list endpoint only returns id and name.

Currently, the options are:

1. Create separate PHP DTO classes for each variant — leads to class proliferation and duplication
2. Use #[Hidden] — but this is destructive (removes from the main type) and not reusable across variants
3. Use #[Optional] at class level — makes everything optional (equivalent to Partial<T>), which is too broad

TypeScript already has the perfect tool for this: Pick<T, K>. It would be ideal if the transformer could generate these automatically.

Proposed Solution

A new #[TypeScriptPick] attribute (or #[TypeScriptPicks] for multiple) that generates named Pick types alongside the main DTO type:

  use Spatie\LaravelData\Data;
  use Spatie\TypeScriptTransformer\Attributes\TypeScript;
  use Spatie\TypeScriptTransformer\Attributes\TypeScriptPick;

  #[TypeScript]
  #[TypeScriptPick('List', ['id', 'name'])]
  #[TypeScriptPick('Card', ['id', 'name', 'email', 'avatar'])]
  class UserData extends Data
  {
      public function __construct(
          public int $id,
          public string $name,
          public string $email,
          public string $avatar,
          public string $phone,
          public string $address,
          public Carbon $created_at,
          // ... many more
      ) {}
  }

Generated TypeScript:

  export type UserData = {
      id: number;
      name: string;
      email: string;
      avatar: string;
      phone: string;
      address: string;
      created_at: string;
      // ...
  };

  export type UserDataList = Pick<UserData, 'id' | 'name'>;
  export type UserDataCard = Pick<UserData, 'id' | 'name' | 'email' | 'avatar'>;

Usage in Front-end

  // API response typing
  const users: UserDataList[] = await fetch('/api/users').then(r => r.json());

  // Component props
  function UserCard({ user }: { user: UserDataCard }) { ... }

Implementation Notes

The attribute could be implemented as a Repeatable attribute targeting classes:

  #[Attribute(Attribute::TARGET_CLASS | Attribute::IS_REPEATABLE)]
  class TypeScriptPick
  {
      public function __construct(
          public string $suffix,
          public array $properties,
      ) {}
  }

On the transformer side, each #[TypeScriptPick] would produce an additional Transformed object containing:

  new TypeScriptAlias(
      name: $className . $suffix,          // e.g. "UserDataList"
      type: new TypeScriptGeneric(
          new TypeScriptIdentifier('Pick'),
          [
              $typeReference,              // reference to the base UserData type
              new TypeScriptUnion(         // 'id' | 'name'
                  array_map(fn($p) => new TypeScriptLiteral("'$p'"), $properties)
              ),
          ]
      )
  );

This means the transformer (or a dedicated TransformedProvider) would need to emit multiple Transformed objects per class, one for the base type, plus one per #[TypeScriptPick].

Alternatives Considered

• #[TypeScriptOmit] — the inverse (Omit<UserData, 'phone' | 'address'>) could also be useful, especially when you want most properties. Could be a companion attribute.
• Inline syntax — #[TypeScriptPicks(['List' => ['id', 'name'], 'Card' => [...]])] — more compact but less readable than repeatable attributes.

Why This Matters

This is a common pain point in Laravel + TypeScript projects, at least for me. TypeScript's utility types exist precisely for this purpose — the transformer could leverage them.