Skip to content

Latest commit

 

History

History
137 lines (97 loc) · 4.32 KB

CONTRIBUTING.md

File metadata and controls

137 lines (97 loc) · 4.32 KB

Contributing

Default commands

Explanation of usage of scripts in package.json.

build

Build this project in dist folder.

prepare:docs

Fix betterdocs template for jsdoc and make it work.

build:docs

Generate documentation with jsdoc.

demo

Start a sample integration vue dev server.

⚠️ If you have this error when trying to run demo:

npm warn reify The "linked" install strategy is EXPERIMENTAL and may contain bugs.
npm error Cannot read properties of undefined (reading 'path')

You have to configure npm with:

npm config set install-strategy hoisted

lint

Run eslint check on the project.

lint:fix

Apply default fix for eslint in project.

lint:report

Generate report of lint issues for sonar.

lint:watch

To use in development, to see current lint errors with auto-refresh.

test

Run all the unit tests.

test:coverage

Generate coverage report of the unit tests.

Development

Directory structure

This is the default directory structure we use for this project:

leto-modelizer-plugin-core
├ cypress              ⇨ Contains all the cypress related files
│ ├ e2e                ⇨ Contains all the e2e tests
│ └ support            ⇨ Contains all support files for e2e tests
│   └ step_definitions ⇨ Contains all step definitions for e2e tests
├ demo                 ⇨ Contains a vue demo application
├ dist                 ⇨ Contains the built application
├ docs                 ⇨ Contains all files generated by esdoc
├ public               ⇨ Contains all public files, like favicon
├ reports              ⇨ Contains all the report files for sonar
├ guides               ⇨ Contains all the guides
├ └  docs              ⇨ Contains all plugin-core documentation
│ └  migrations        ⇨ Contains all migration guides
│ └  svg               ⇨ Contains the guide to build a component svg
├ src                  ⇨ Contains all files for modeling tools
│ ├ assets             ⇨ Contains all the assets
│ ├ draw               ⇨ Contains all files related to the Class that draws components in a graphical representation
│ ├ error              ⇨ Contains all files related to the Class that represents a parsing error
│ ├ metadata           ⇨ Contains all files related to the Class that represents the metadata of a specific implementation
│ ├ models             ⇨ Contains all files related to the Class that represents default plugin structure
│ ├ parser             ⇨ Contains the Class used for parsing
│ └ render             ⇨ Contains the Class that compile components to data
└ tests                ⇨ Contains all files related to the tests

How to release

We use Semantic Versioning as guideline for the version management.

Steps to release:

  • Checkout a branch release/vX.Y.Z from the latest dev.
  • Increase your version number in package.json, package-lock.json and changelog.md.
  • Verify the content of the changelog.md.
  • Build the project
  • Commit your modification (with the dist content) with this commit's name Release version X.Y.Z.
  • Create a pull request on github to this branch in dev.
  • After the previous PR is merged, create a pull request on github to dev in main.
  • After the previous PR is merged, tag the main branch with vX.Y.Z
  • After the tag is push, make the release on the tag in GitHub

Git: Default branches

The default branch is main, we can't commit on it and we can only make a pull request to add some code.

Release tags are only on the main branch.

Git: Branch naming policy

There is the branch naming policy: [BRANCH_TYPE]/[BRANCH_NAME]

  • BRANCH_TYPE is a prefix to describe the purpose of the branch, accepted prefix are:
    • feature, used for feature development
    • bugfix, used for bug fix
    • improvement, used for refacto
    • library, used for updating library
    • prerelease, used for preparing the branch for the release
    • release, used for releasing project
    • hotfix, used for applying a hotfix on main
  • BRANCH_NAME is managed by this regex: [a-z0-9_-] (_ is used as space character).

Examples:

# BAD
add_some_test
# GOOD
improvement/unit_test

# BAD
feature/adding-some-feature
# GOOD
feature/adding_some_feature