Installations

npm install tsoa

Pull Requests

Open

8

Total

634

Closed

125

Merged

501

Issues

Open

108

Total

1,088

Closed

980

Releases

97

v6.5.0

Published on 14 Oct 2024

v6.4.0

Published on 12 Jul 2024

v6.3.1

Published on 12 Jun 2024

v6.3.0

Published on 08 Jun 2024

v6.2.1

Published on 24 Apr 2024

v6.2.0

Published on 24 Mar 2024

View all 97 releases

Developer

lukeautry

Developer Guide

BETA

Module System

CommonJS

Min. Node Version

>=18.0.0

Typescript Support

No

Node Version

22.9.0

NPM Version

lerna/8.1.8/node@v22.9.0+x64 (linux)

Statistics

3,595 Stars

1,904 Commits

503 Forks

28 Watching

27 Branches

173 Contributors

Updated on 28 Nov 2024

Languages

TypeScript (96.53%)

Handlebars (2.24%)

JavaScript (1.23%)

Total Downloads

Cumulative downloads

Total Downloads

20,811,583

Last day

-16%

30,526

Compared to previous day

Last week

-6.6%

181,441

Compared to previous week

Last month

10.8%

836,375

Compared to previous month

Last year

28.2%

7,709,002

Compared to previous year

Daily Downloads

Weekly Downloads

Monthly Downloads

Yearly Downloads

Dependencies

2

@tsoa/cli @tsoa/runtime

Dev Dependencies

2

@types/node typescript

Versions

tsoa

Pronounced so·uh

OpenAPI-compliant REST APIs using TypeScript and Node

Goal

TypeScript controllers and models as the single source of truth for your API
A valid OpenAPI (formerly Swagger) spec (2.0 or 3.0 if you choose 😍) is generated from your controllers and models, including:
- Paths (e.g. GET /users)
- Definitions based on TypeScript interfaces (models)
- Parameters/model properties marked as required or optional based on TypeScript (e.g. myProperty?: string is optional in the OpenAPI spec)
- jsDoc supported for object descriptions (most other metadata can be inferred from TypeScript types)
Routes are generated for middleware of choice
- Express, Hapi, and Koa currently supported, other middleware can be supported using a simple handlebars template
- Validate request payloads

Philosophy

Rely on TypeScript type annotations to generate API metadata if possible
If regular type annotations aren't an appropriate way to express metadata, use decorators
Use jsdoc for pure text metadata (e.g. endpoint descriptions)
Minimize boilerplate
Models are best represented by interfaces (pure data structures), but can also be represented by classes
Runtime validation of tsoa should behave as closely as possible to the specifications that the generated OpenAPI 2/3 schema describes. Any differences in validation logic are clarified by logging warnings during the generation of the OpenAPI Specification (OAS) and/or the routes.
- Please note that by enabling OpenAPI 3 you minimize the chances of divergent validation logic since OpenAPI 3 has a more expressive schema syntax.

Getting Started

Examples

Check out the guides

See example controllers in the tests

See example models in the tests

Help wanted

Contributing code

To contribute (via a PR), please first see the Contributing Guide

Becoming a maintainer

tsoa wants additional maintainers! The library has increased in popularity and has quite a lot of pull requests and issues. Please post in this issue if you're willing to take on the role of a maintainer.

No vulnerabilities found.

10

Maintained

Determines if the project is "actively maintained".

10

Dangerous-Workflow

Determines if the project's GitHub Action workflows avoid dangerous patterns.

10

Binary-Artifacts

Determines if the project has generated executable (binary) artifacts in the source repository.

10

License

Determines if the project has defined a license.

9

Security-Policy

Determines if the project has published a security policy.

7

Vulnerabilities

Determines if the project has open, known unfixed vulnerabilities.

5

Code-Review

Determines if the project requires human code review before pull requests (aka merge requests) are merged.

0

Token-Permissions

Determines if the project's workflows follow the principle of least privilege.

0

Pinned-Dependencies

Determines if the project has declared and pinned the dependencies of its build process.

0

CII-Best-Practices

Determines if the project has an OpenSSF (formerly CII) Best Practices Badge.

0

Fuzzing

Determines if the project uses fuzzing.

0

Branch-Protection

Determines if the default and release branches are protected with GitHub's branch protection settings.

0

SAST

Determines if the project uses static code analysis.

Score

5.1

/10

Last Scanned on 2024-11-18

The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.

Learn More