Repository navigation
feat(openapi-resource-gen): accept Swagger 2.0 specs by converting them to OpenAPI 3.0 in memory - #82
Merged
Merged
Conversation
…em to OpenAPI 3.0 in memory Swagger 2.0 specs used to be rejected with "convert first with swagger2openapi". They are now converted in memory with @scalar/openapi-upgrader (a notice is printed, the spec on disk is untouched) and generated as usual; the new `convertSwagger2: false` rejects them instead. Swagger 1.x is still rejected, and the error now names both supported formats. The upgrader applies a global `produces` even to operations that override it, which turned an `image/png` download into JSON and made the generator pick the wrong response variant. swagger2.ts therefore pushes the global `produces` / `consumes` down into operations that lack their own before converting. The upgrader also mutates its input, so it is given a copy. The upgrader is ESM-only and the generator is CommonJS: it is loaded with require() (Node >= 20.19 / 22.12) and falls back to a dynamic import() when require reports ERR_REQUIRE_ESM (verified on Node 20.18 and 24). Tests: unit tests for the module and the conversion wiring (replacing a test that only asserted its own error text), plus an integration test that runs the real generator and parser on a realistic Swagger 2.0 spec (global produces with overrides, a file download, multipart formData, collectionFormat, shared parameters/responses, securityDefinitions) and compiles the output. The integration helper is shared with the readWriteMarkers spec and excluded from the library build. The compat Nx harness installs the upgrader and runs a Swagger 2.0 generation on every Nx version. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Quick win #4 from the roadmap (
docs/roadmap/quick-wins.md).The problem
Swagger 2.0 specs were rejected with "convert first with swagger2openapi". Hey API and OpenAPI Generator accept them, and many real APIs still publish 2.0.
The change
Point
specPathat a Swagger 2.0 spec and the generator converts it to OpenAPI 3.0 in memory (with@scalar/openapi-upgrader, actively maintained;swagger2openapiwas last published in 2022), prints a one-line notice, and generates as usual. The spec on disk is untouched. New optionconvertSwagger2(defaulttrue);falserejects Swagger 2.0 instead. Swagger 1.x is still rejected, with a message naming both supported formats.An upgrader bug worked around
When a spec has a global
produces(nearly all do) and an operation overrides it, the upgrader applies the global one to responses. A download declaringproduces: [image/png]came out asapplication/json, so the generator would type a file download as JSON.swagger2.tspushes the globalproduces/consumesdown into operations that lack their own before converting, so each operation's declared types win. (The upgrader also mutates its input, so it gets a copy.) Reported here so it can be raised upstream.ESM-only dependency in a CommonJS generator
The upgrader is ESM-only. It is loaded with
require()(works on Node ≥ 20.19 / 22.12) and falls back to a dynamicimport()whenrequirereportsERR_REQUIRE_ESM. Verified on real Node 20.18 (fallback path) and Node 24 (direct path) against the built package, and on every Nx version in the compat matrix.Verification
Errorand asserted its own text.produceswith overrides, afiledownload, multipartformData,collectionFormat, shared parameters/responses,securityDefinitions), with the output compiled by TypeScript; checks a blob download, a text response, a multipart body,join('|')serialization, a typed 404 error, and one security token per scheme. Also with--clientType=httpClient.tsc, anduploadFilecorrectly becomes amultipart/form-databodyNotes
@scalar/openapi-upgrader(declared in the package and the workspace root). The integration test helper is shared with thereadWriteMarkersspec and is excluded from the library build so it doesn't ship (caught while preparing this).CLAUDE.mdpipeline step, schema input and decision row.🤖 Generated with Claude Code