The MANUALLY written types from chapter 75 get OUT OF SYNC AS SOON as the API changes – openapi-typescript generates them AUTOMATICALLY from the specification from chapter 17 INSTEAD.

Installing the tool

npm install --save-dev openapi-typescript

Generation as an npm script

{
  "scripts": {
    "generate-types": "openapi-typescript https://localhost/api/docs.jsonopenapi --output src/types/api.ts"
  }
}

docs.jsonopenapi is API Platform's JSON endpoint for the RAW OpenAPI specification (EXACTLY the content from chapter 17's api:openapi:export, here fetched DIRECTLY over HTTP instead of via the console).

npm run generate-types

Using the generated types

import type { components } from '../types/api';

type Project = components['schemas']['Project.jsonld-project.read'];
type ProjectCollection = components['schemas']['Project.jsonld-project.read.collection'];

The generated type names CONTAIN the serialization group (chapter 23) – VISIBLE proof that the generated types EXACTLY reflect WHICH fields actually exist in WHICH situation, instead of making a BLANKET assumption.

Replacing the manual type

// hooks/useProjects.ts - BEFORE (chapter 75)
import type { ProjectCollection } from '../types/project';

// AFTER
import type { components } from '../types/api';
type ProjectCollection = components['schemas']['Project.jsonld-project.read.collection'];

Automation, a preview

In a REAL team, generate-types would be part of the CI workflow (blocks 11-12 cover deployment in depth) – if the API structure CHANGES, a tsc type check FAILS instead of SILENTLY masking wrong assumptions in the frontend.