Socket
Socket
Sign inDemoInstall

freight-shipment-system-schemas

Holds all schemas and data models for the Freight Shipment System


Version published
Maintainers
1
0

Weekly downloads

Readme

Source

Freight Shipment API Schemas

Contents

This repository holds the raw OAS documents for Freight Shipment APIs at DAT. The master branch should always be in sync with the Freight Shipment Redocly Project.

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 Stoplight.

The first time you clone this repository you will want to do the following:

  1. execute npm ci
  2. execute npm run bootstrap

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 script npm run build:dist.

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.

Merging PR with updated version

Once you have made changes in API and created PR, please DON'T merge it until a feature that uses this API is not ready. It is important to merge PR with updated API version right before merging PR with a feature. For local testing it is possible to replace the package in node_modules or use npm link.

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.

Keywords

FAQs

Last updated on 01 Aug 2022

Did you know?

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc