UNPKG

baqend

Version:

Baqend JavaScript SDK

96 lines (63 loc) 3.31 kB
Contributing ============ We are working on a feature branch basis. That means, if you want to impelement a new feature, refactor something, or add any other change, you branch you feature branch of the master branch. That is the branch on which you will do you work. The following sections will tell you how you should you feature branches, how to keep your feature branch up to date and how to write good commit messages. Feature branch mames -------------------- Branches should fulfill the following name scheme: <year>/<calendarweek>/<kind>/<name_with_underscores> For example: 2023/44/feat/disable_speed_kit_on_many_errors 2023/27/fix/implement_feature_xyz Keeping your feature branch up to date -------------------------------------- Make sure to regularily __rebase__ your feature branch onto the master branch to prevent diverging too much from it. You might miss changes which could touch the files you're working on which will result in a lot of merge conflicts. The simplest way to do that is by using IntelliJ: * Check out your feature branch * Updat the master branch * Rebase your branch onto the master branch by selecting the master branch and choosing `Rebase current onto selected` Take a look [here](https://www.jetbrains.com/help/idea/apply-changes-from-one-branch-to-another.html#rebase-branch) for more details on how to properly rebase with IntelliJ. Commit message format and content --------------------------------- Commits should have the following scheme: <kind>(<scope>): <message> With the following values for `<kind>`: - **feat:** new feature - **fix:** bug fix - **refactor:** refactoring production code - **style:** formatting, missing semi colons, etc; no code change - **docs:** changes to documentation - **test:** adding or refactoring tests; no production code change - **chore:** updating grunt tasks etc; no production code change The `<scope>` is optional but we encourage to use them for better separation of commits within a branch. Example values could be: assets, server, build, general For example: feat(server): Implement changeOrigin on AssetAPI The commit message should contain a short explanaition what the commited change is doing. There is no need in repeating t the change itself since it's self explainatory by the code change. Please refer to [this article](https://chris.beams.io/posts/git-commit/#imperative) to to see how to write good commit messages. Run the tests locally --------------------- There are two types of tests. Before you can run the tests you need to build the project with: ```bash npm run build dist ``` The node base tests can then be started with: ```bash npm run test:node ``` The node tests can also be started with the build in mocha runner of IntelliJ. The browser based test can be used with your local installed chrome with: ```bash npm run test:browser ``` Test a specific browser engine with playwright runner use one of the following commands. Read more about it in the [offical documentation](https://modern-web.dev/docs/test-runner/browser-launchers/playwright/). ```bash npm run test:browser -- --playwright --browsers chromium npm run test:browser -- --playwright --browsers firefox npm run test:browser -- --playwright --browsers webkit ```