npm package: @skedulo/mex-types
Description: A central repository store for all the interfaces, type definitions of MEX engine
Author: Skedulo
Latest version: 1.58.0

# 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

```sh
yarn bootstrap
```

## How to test the package locally
From the root of **mex-types**, run

```sh
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
```json
"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](https://github.com/semantic-release/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](https://www.conventionalcommits.org/en/v1.0.0/) 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 <br><br>BREAKING CHANGE: The graphiteWidth option has been removed.<br>The default graphite width of 10mm is always used for performance reasons.` | ~~Major~~ Breaking Release <br /> (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](https://skedulo.atlassian.net/wiki/spaces/RS/pages/2647785497/Mex-Types+Trigger+release+pipeline) to trigger release manually