@skedulo/mex-types

mex-types

A central repository store for all the interfaces, type definitions of MEX engine. It also includes scripts that can read information from TypeScript files, which contain these interfaces and definitions. The data extracted from these files is then used by the Form Builder.

Node version

18.x

Install

Bootstrap

yarn bootstrap

How to test the package locally

From the root of mex-types, run

yarn clean
yarn build
npm pack --pack-destination /tmp

After this step, you should see a new file in the /tmp folder

• For example: /tmp/skedulo-mex-types-0.0.1.tgz

Inside project uses this package, update package.json to point to *.tgz above

"dependencies": {
  "@skedulo@mex-types": "file:/tmp/skedulo-mex-types-0.0.1.tgz"
}

Semantic release

This project adheres to the Semantic Versioning (SemVer) release approach, and as such, we employ the tool Semantic Release to facilitate automated version incrementation.

Commit message convention

Tips: To simplify the process of creating commit messages that adhere to the Conventional Commits format, consider using the Commitizen tool. After you've staged all your changes, you can run either yarn commit or git cz. This tool will guide you through the process and make it easier to generate the correct commit message format.

Please use the guidelines outlined in this guide when writing your commit messages. Following this guide ensures that your commit messages follow a standard format. This standard format is important because it helps the semantic-release tool understand and manage versioning more effectively.

The table below shows which commit message gets you which release type when semantic-release runs (using the default configuration):

Commit message	Release type
fix(api): resolve issue with data parsing	Patch Fix Release
feat(login): add user authentication feature	Minor Feature Release
feat(login): No backward compatibility BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reasons.`	Major Breaking Release (Note that the BREAKING CHANGE: token must be in the footer of the commit)

Publish workflow

Release channel

main branch

Pre-release channel

beta branch (Must be branched from main)

New feature (Pre-release) flow:

• Create a branch from beta
• Implement the feature
• Raise PR from new branch into beta
• After approved, using squash merge. Please enter commit message following conventional guidelines
  • At this stage, your beta version is ready to install. It might have a format like this 1.0.1-beta. (There is a bot will comment on your PR about new version after semantic-release publishing successfully.)
• Raise PR from beta to main
• Wait for approval and squash merge

Hot fix

• Create a branch from main
• Implement the fix
• Raise PR from new branch into main
• After approved, using squash merge.(Please use fix convention message)

Release type rules

• If adding comments into the code that affect the output of parsed info, must release in patch type. Here are list of change might contribute to parsed output
  • jsdocs comment
  • the parser scripts get updated
• If add new property, interface, type defs, must release in minor type
• Break change (TBD)

Trigger release manually

Please follow this guidelines to trigger release manually