A central repository store for all the interfaces, type definitions of MEX engine
npm install @skedulo/mex-typesA 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.
Bootstrap
``sh`
yarn bootstrap
`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"
}
This project adheres to the Semantic Versioning (SemVer) release approach, and as such, we employ the tool Semantic Release to facilitate automated version incrementation.
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) |
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)