0a70aa7f61
Versioning library is a big mess of things all into one file, this makes it hard to contribute. Did this originally because I was going to deal with multiple madeRequired and madeOptional over time but that will be done later but finished the cleanup anyway. Split the versioning.ts into multiple separate logical files: - `decorators.ts`: Contains all the versioning decorators and accessor - `internal-projection-functions.ts`: Contains implementation of the helper function used inside the versioning projection(not meant for external use) - `projection.ts`: Contains the projection building functions - `versioning.ts`: Contains the various versioning computation function(timeline, etc.) This makes it clearer of what is supposed to be public apis vs internal, waht is just mean for decorator, projection, etc. |
||
---|---|---|
.chronus | ||
.github | ||
.vscode | ||
blog/2024-04-25-introducing | ||
docker | ||
docs | ||
e2e | ||
eng | ||
grammars | ||
icons/raw | ||
packages | ||
.dockerignore | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
.npmrc | ||
.prettierignore | ||
.prettierrc.json | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
LICENSE | ||
README.md | ||
SECURITY.md | ||
cspell.yaml | ||
eslint.config.js | ||
package.json | ||
pnpm-lock.yaml | ||
pnpm-workspace.yaml | ||
troubleshooting.md | ||
tsconfig.base.json | ||
tsconfig.eng.json | ||
tsconfig.json | ||
tsconfig.ws.json | ||
vitest.config.ts | ||
vitest.workspace.ts |
README.md
TypeSpec
Official Docs | Try TypeSpec Online | Getting Started | Language Overview
TypeSpec is a language for defining cloud service APIs and shapes. TypeSpec is a highly extensible language with primitives that can describe API shapes common among REST, OpenAPI, gRPC, and other protocols.
TypeSpec is excellent for generating many different API description formats, client and service code, documentation, and many other assets. All this while keeping your TypeSpec definition as a single source of truth.
Using TypeSpec, you can create reusable patterns for all aspects of an API and package those reusable patterns into libraries. These patterns establish "guardrails" for API designers and makes it easier to follow best practices than to deviate from them. TypeSpec also has a rich linter framework with the ability to flag anti-patterns as well as an emitter framework that lets you control of the output to ensure it follows the patterns you want.
Installation
npm install -g @typespec/compiler
Tools
The TypeSpec VS Code extension can be installed from the VS Code marketplace or directly on the command line:
tsp code install
The TypeSpec VS Extension can be installed from the VS Marketplace or directly on the command line:
tsp vs install
Usage
TypeSpec to OpenAPI 3.0 Example
This example uses the @typespec/http
, @typespec/rest
, and @typespec/openapi3
libraries to define a basic REST service and generate an OpenAPI 3.0 document from it.
Run the following command and select "Generic REST API":
tsp init
Hit enter a few times to confirm the defaults.
Copy the contents below into your main.tsp:
import "@typespec/http";
import "@typespec/rest";
import "@typespec/openapi3";
using TypeSpec.Http;
using TypeSpec.Rest;
/** This is a pet store service. */
@service({
title: "Pet Store Service",
})
@server("https://example.com", "The service endpoint")
namespace PetStore;
@route("/pets")
interface Pets {
list(): Pet[];
}
model Pet {
@minLength(100)
name: string;
@minValue(0)
@maxValue(100)
age: int32;
kind: "dog" | "cat" | "fish";
}
Install the dependencies of main.tsp:
tsp install
Compile it to OpenAPI 3.0:
tsp compile main.tsp --emit @typespec/openapi3
You can find the emitted OpenAPI output in ./tsp-output/openapi.json
.
Advanced Scenarios
Installing nightly version
On every commit to the main branch, packages with changes are automatically published to npm with the @next
tag.
The packages section shows which version corresponds to the next
tag for each package.
To use a nightly
version of the packages, go over each one of the packages in the package.json
file and update it to either the latest published @next
version or @latest
, whichever is the newest. You can also use the tag latest
or next
instead of an explicit version.
After updating the package.json file you can run npm update --force
. Force is required as there might be some incompatible version requirement.
Example
// Stable setup
"dependencies": {
"@typespec/compiler": "~0.30.0",
"@typespec/http": "~0.14.0",
"@typespec/rest": "~0.14.0",
"@typespec/openapi": "~0.9.0",
}
// Consume next version
// In this example: compiler and openapi have changes but rest library has none
"dependencies": {
"@typespec/compiler": "~0.31.0-dev.5",
"@typespec/http": "~0.14.0",
"@typespec/rest": "~0.14.0", // No changes to @typespec/rest library so need to stay the latest.
"@typespec/openapi": "~0.10.0-dev.2",
}
Packages
Name | Changelog | Latest | Next |
---|---|---|---|
Core functionality | |||
@typespec/compiler | Changelog | ||
TypeSpec Libraries | |||
@typespec/http | Changelog | ||
@typespec/rest | Changelog | ||
@typespec/openapi | Changelog | ||
@typespec/openapi3 | Changelog | ||
@typespec/versioning | Changelog | ||
TypeSpec Tools | |||
@typespec/prettier-plugin-typespec | Changelog | ||
typespec-vs | Changelog | ||
typespec-vscode | Changelog | ||
tmlanguage-generator | Changelog |
@next
version of the package are the latest versions available on the main
branch.