# openapi-typescript-codegen tells you to migrate, then asks for sponsors

> A Node.js library that generates TypeScript or JavaScript clients from an OpenAPI specification. Its own README opens by declaring the project unmaintained, naming a fork as the successor, and promising that every version will be deprecated on npm, which is the first thing to read before choosing it.

**ferdikoomen/openapi-typescript-codegen** — NodeJS library that generates Typescript or Javascript clients based on the OpenAPI specification

- Repository: https://github.com/ferdikoomen/openapi-typescript-codegen
- Stars: 3,370 · Forks: 546
- Language: TypeScript
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/ferdikoomen-openapi-typescript-codegen

## The README opens by telling you to leave

The file begins with a heading reading Important announcement and an IMPORTANT callout, before the project even introduces itself. It asks readers to migrate their projects to `@hey-api/openapi-ts`, giving the fork's repository. The stated reason is time limitations on the author's side, with the sentence that this project has been unmaintained for a while now. It explains that `@hey-api/openapi-ts` started as a fork with the goal of resolving the most pressing issues, and that its maintainers are planning to keep maintaining the OpenAPI generator. Then two dated commitments: all open pull requests and issues will be archived on the 1st of May 2024, and all versions of the package will be deprecated on npm. A migration guide is linked. So the positioning of this repository in the ecosystem is now unambiguous, and it is written by the author rather than inferred: this is the package you are meant to move off, and the successor is named in the same paragraph.

## The deprecation notice and the release list do not line up

Set the announcement against what the repository has actually done since. The notice commits to archiving everything open on 1 May 2024. The release list shows `v0.29.0` on 2024-04-07, which fits that timeline, and then two releases well after it: `v0.30.0` on 2025-12-22 and `v0.31.0` on 2026-06-20. The manifest agrees with the newest tag, carrying version `0.31.0`. The last push to the repository was on 2026-10-04. None of that changes the announcement, and this article is not going to explain it, because the file offers no explanation. What it does mean is that neither signal alone tells you what to do. The README is the author's stated intent, the tags are the artifact history, and the two disagree about whether the project is finished. For an engineer holding this dependency, the practical question is not which document is newer but what your upgrade path is, and that question is answered by the fork's migration guide rather than by anything in this repository.

## A sponsorship appeal sits underneath the unmaintained notice

The document contradicts itself within its own length, and the second half is the part people tend to find. After the project description, the usage block and a pointer to the documentation, there is a Sponsors section that asks readers to consider supporting the author, on the grounds that by sponsoring, time can be freed up to give the project some love, with a link to the GitHub sponsors page. So the file that declares the project unmaintained for lack of time, and that names a fork taking over, also solicits sponsorship to continue the work. That is not necessarily dishonest. A maintainer can hold both positions: the codebase needs a fork that will carry it forward, and the original still needs maintenance while users migrate off it. But it does mean the README cannot be read as a single statement, and it means the sponsorship pitch is aimed at teams that are being told to leave. If you are making this decision for an organisation, note that supporting this project is a decision about the transition period, not about where the generator will end up.

## The help text ends mid-sentence on the last option

The usage section is the whole CLI contract, and it is reproduced from the tool's own help output:

```
$ openapi --help

  Usage: openapi [options]

  Options:
    -V, --version             output the version number
    -i, --input <value>       OpenAPI specification, can be a path, url or string content (required)
    -o, --output <value>      Output directory (required)
    -c, --client <value>      HTTP client to generate [fetch, xhr, node, axios, angular] (default: "fetch")
    --name <value>            Custom client class name
    --useOptions              Use options instead of arguments
    --useUnionTypes           Use union types instead of enums
    --exportCore <value>      Write
```

The final option is the interesting one. `--exportCore` takes a value, and its description is the single word Write, ending the block mid-thought. So a flag whose name suggests it controls whether core files are exported ships with an undocumented value set and an unfinished explanation. Everything above it is complete and unusually informative: `-i` accepts a path, a URL or string content, which means the specification does not have to be a file on disk; `-c` names five targets with `fetch` as the default; and the three bare flags cover the naming and type-style choices most projects argue about.

## npm test runs only the UNIT project, while clean knows about e2e

The manifest is small and mostly legible, with one gap worth naming. The test script is `jest --selectProjects UNIT`, and the tree's jest configuration is a file rather than a key in the package manifest, so it defines more than one project. The clean script is the evidence: it removes `./dist`, `./test/generated`, `./test/e2e/generated`, `./samples/generated`, `./coverage` and `./node_modules/.cache`. A clean step that deletes `test/e2e/generated` is cleaning output that `npm test` never produces, so there is an end-to-end project in the jest configuration that the default test command excludes. There is also a separate `run` script that executes `node ./test/index.js` directly, a hand-driven harness outside jest. The other scripts are tidy in a way that is easy to miss: `build` and `release` are the same rollup invocation differing only in `NODE_ENV`, so there is one pipeline with two environments rather than two pipelines. `validate` is a type-check only, `tsc --noEmit`.

## The Docker image builds from a floating base and ships the source tree

There is a Dockerfile at the root and it is five instructions long. It starts `FROM node:alpine` with no tag and no digest, so the base image floats and the build is not reproducible over time. It sets a work directory, copies the entire build context into it, runs `npm install`, runs `npm run release`, and then sets an entrypoint of `node` against `bin/index.js` with a default command of `--help`. Two consequences. First, `npm install` rather than `npm ci` means the image resolves dependencies fresh on every build, so a lockfile that exists in the tree is not being honoured. Second, the whole repository is copied in before the build runs, so the resulting image carries the source tree and its installed modules rather than only the three published files. There is also a `.licrc` file at the root, a licence-header configuration, alongside a `Dockerfile`, `babel.config.json`, an eslint flat config at `eslint.config.mjs`, a rollup config, and a `samples/` directory holding a shell script and a spec directory for trying the generator against a fixed input.

## The published package is three files and the documentation is a wiki

The `files` array is the whole publication policy and it contains three entries: `bin/index.js`, `dist/index.js` and `types/index.d.ts`. Everything else in the repository, the samples, the tests, the rollup configuration and the source, is development material that does not ship. So a consumer installs a CLI plus one bundle plus one type declaration file, and nothing else. The `bin` key maps the name `openapi` to `bin/index.js`, `main` points at `dist/index.js` and `types` at `types/index.d.ts`, which is consistent with the build producing a single rollup bundle. The documentation is the weakest part of that arrangement for a project in this position. It lives in the repository wiki, linked from the README, with no docs site and no docs directory in the tree. For a maintained project that is unusual; for one whose author is asking you to migrate, it means the reference material is hosted in the same place as the code and inherits the same uncertainty.

## Conclusion

openapi-typescript-codegen suits an existing project that has already adopted it and needs to keep generating until a migration is scheduled, because its command line is short and its five client targets are documented. It does not suit a new adoption, because the author has said in the README that the project is unmaintained, that the fork named there is taking it over, and that all versions will be deprecated on npm. Before you start anything new here, read the migration guide the announcement links and read the deprecation date with it. The last push to this repository was on 2026-10-04 and the newest release is v0.31.0 from 2026-06-20, so the repository is not frozen even though the announcement says the project is.

## FAQ

### what is openapi typescript codegen

A Node.js library that generates TypeScript or JavaScript clients from an OpenAPI specification, supporting specification v2.0 and v3.0, JSON or YAML input, and generating fetch, XHR, node, axios or angular clients. Its author states in the README that the project has been unmaintained for a while and asks users to migrate to @hey-api/openapi-ts.

### how to use openapi typescript codegen

Install it with `npm install openapi-typescript-codegen --save-dev` and run the `openapi` binary. It requires `-i` for the specification, which accepts a path, a URL or string content, and `-o` for the output directory, with `-c` choosing the HTTP client and defaulting to fetch.

### What should I use instead of openapi-typescript-codegen?

@hey-api/openapi-ts. The announcement says that project started as a fork to resolve the most pressing issues, that its maintainers plan to keep maintaining the generator, that open pull requests and issues were to be archived on 1 May 2024, and that all versions of this package will be deprecated on npm. A migration guide is linked from the README.

### Which HTTP clients can openapi-typescript-codegen generate?

Five, selected with `-c`: fetch, xhr, node, axios and angular, with fetch as the default. The command also accepts `--name` for a custom client class name, `--useOptions` to use options instead of arguments, and `--useUnionTypes` to use union types instead of enums.

### Where is the documentation for openapi-typescript-codegen?

In the repository wiki, linked from the README. The tree has no docs directory; it has a samples directory with a codegen shell script and a spec directory, plus a jest configuration and a test directory.

## Sources

- [ferdikoomen/openapi-typescript-codegen on GitHub](https://github.com/ferdikoomen/openapi-typescript-codegen)
- [Issues](https://github.com/ferdikoomen/openapi-typescript-codegen/issues)
- [License: MIT](https://github.com/ferdikoomen/openapi-typescript-codegen/blob/main/LICENSE)
- [README](https://github.com/ferdikoomen/openapi-typescript-codegen/blob/main/README.md)
- [Releases](https://github.com/ferdikoomen/openapi-typescript-codegen/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ferdikoomen-openapi-typescript-codegen