freight-customer-integrations-api-schemas v1.0.69

Freight Customer Integrations API Schemas

Contents

This repository holds the raw OAS documents for Freight Customer Integrations APIs at DAT.

Contributing

Changes to these schemas should be done in a feature branch and reviewed by the Freight development teams before being merged into the master branch and ported into Redocly.

The first time you clone this repository you will want to do the following: 1. execute npm ci 2. execute npm run bootstrap or for Windows npm run bootstrap:win

General Assumptions

This project assumes that any OAS documents you want to generate TS models from and dereference are located under the packages directory and contain .oas2 or .oas3 (case-insensitive) in the filename.

To simplify how the code generation processes each respective package, it assumes that the directory name underneath the packages directory matches exactly with its respective npm package name that appears after the scope prefix. (ex: packages/my-cool-api --> @dat/my-cool-api)

Generating TS models

Once you feel your OAS changes are complete the next step is to generate the corresponding TypeScript models from them. This project leverages lerna as a tool for managing monorepos, so the models for all OAS files can be generated at once by running the npm scripts npm run build and then (npm run build:dist or for Windows npm run build:dist:win.

Make sure you've created an access token for your Redocly profile and set it as a system environment variable, ex: $: export REDOCLY_TOKEN=<YOUR ACCESS TOKEN>

Updating the versions properly

Please follow the semver guidance to decide whether to bump the OAS document's version's major, minor, or patch value.

Note: The package.json version field is independent of OAS versions. This is because any given API schemas npm package may or may not export multiple OAS documents and models which may lead to incompatibility and confusion when trying to synchronize them.

Publishing your changes

With the option we use for lerna to publish the packages, we only need to worry about updating the version in the package.json file to the desired value. Once the PR is approved and merged, then the CI pipeline will execute the npm run publish command, and any changed packages will be published to the npm registry under our @dat scope.