feat: add /api endpoint returning OpenAPI 3.0.0 specification

[MridulTailor]

Type of Change

• Routes: Added /api endpoint in src/routes/api.ts which returns an OpenAPI 3.0.0 specification dynamically generated from the existing Zod schemas using OpenAPIRegistry. Integrated into src/index.ts.
• Utilities: Added src/utils/openapi.ts to globally initialize extendZodWithOpenApi(z).
• Tests: Added src/routes/api.spec.ts with 7 tests covering CORS headers, cache headers, status codes, trailing slash resolution, and structural validation of the returned OpenAPI JSON spec.

What issue does this relate to?

Closes #189

What should this PR do?

• Introduce a new /api endpoint that returns an OpenAPI 3.0.0 JSON specification for the cdnjs API.
• Introduce @asteasolutions/zod-to-openapi as a dependency to dynamically generate the OpenAPI definitions directly from existing Zod schemas (library.schema.ts, libraries.schema.ts, etc.), ensuring response shapes are never manually duplicated and remain easily maintainable.
• Ensure complex Zod constraints like unions (autoupdate property) and intersections (required: ['name']) are automatically parsed and translated to OpenAPI oneOf/allOf attributes by the library.
• Include a path entry for /api itself and a servers block pointing to https://api.cdnjs.com.
• Use a 6-hour cache (matching libraries.ts and stats.ts) rather than a long-lived immutable cache, keeping the spec updatable as the API evolves.

What are the acceptance criteria?

• The /api endpoint returns a valid OpenAPI JSON object with descriptions matching the original cdnjs API documentation.
• OpenAPI paths and component schemas dynamically and accurately reflect the data returned by the existing endpoints without needing manual mapping.
• Types and lint pass with 0 errors (npm run types, npm run lint).
• Note: The 7 new tests show as skipped due to a pre-existing semver CommonJS module resolution issue in @cloudflare/vitest-pool-workers that affects the entire test suite — unrelated to this PR. See Cloudflare Workers known issues.

[MattIPv4]

Thanks for working on this :)

Please can you generate the OpenAPI response schemas from the Zod schemas we define for each route -- this is not maintainable to have all the response types duplicated and written out manually.

[MattIPv4]

Thanks for working on this, this new approach w/ the Zod-based library looks much better! A few thoughts:

• Running this through https://editor.swagger.io/, it reports that the Error schema is defined but unused, do you need to pass a reference to that when you're defining the 404 responses, instead of using the Zod schema directly there?

• Should all the endpoints also define a 500 response using that schema?

• Should each route be given a tag? Perhaps a libraries tag for the three library routes, and a meta tag for the others (stats, whitelist, api)?

• Can you make sure the documentation you have for each endpoint matches exactly the documentation on the existing API docs, with the correct linebreaks and markdown for code/italics?

  (Don't worry about the documentation for the response schemas, that can be done as a follow-up, so that your changes in this PR remain isolated to just this new route.)

[MridulTailor]

Thanks for the feedback! I've addressed all the points:

• Unused Error schema: The 404 responses for /libraries/:library and /libraries/:library/:version now reference #/components/schemas/Error via $ref instead of inlining the schema directly. Also fixed an empty parameters: {} being generated by zod-to-openapi which was causing a Swagger editor warning.
• 500 responses: Added to all endpoints using a shared errorResponseContent constant.
• Tags: Added libraries tag to the library routes and meta to /stats, /whitelist, and /api.
• Descriptions: Tried to update all endpoint and parameter descriptions to match the live API docs.
• /api response schema: Added a dedicated api.schema.ts file with a Zod schema and exported OpenApiResponse type, following the same pattern as other route schema files.

[MattIPv4]

Thank you! I'll try to take another pass through this later this week. Would you mind resolving the conflicts with the dependency you added (easiest is probably to checkout package* from master, and then reinstall your new dependency).