Skip to content

Latest commit

 

History

History
112 lines (72 loc) · 4.27 KB

CONTRIBUTING.md

File metadata and controls

112 lines (72 loc) · 4.27 KB
Raw

Contribution Guide

This is the common top level contribution guide for this mono-repo. A sub-package may have an additional CONTRIBUTING.md file if needed.

Legal

All contributors must sign the Developer Certificate of Origin (DCO)

SAP uses the standard DCO text of the Linux Foundation.

Guideline for AI-generated code contributions to SAP Open Source Software Projects

Pull Request Guidelines

When contributing a New Feature make sure to:

  • use the feat: prefix in the commit message header.
  • Add relevant test cases to the PR.
  • Describe the reason for this new feature in the PR (The Why, not just How...)
    • For significant changes it is recommended to first open an issue to discuss the proposed feature and ensure it fits the project's goals.

When Fixing a Bug:

  • use the fix: prefix in the commit message header.
  • Add a detailed description of the bug to the PR or open a new issue with the bug's description (if none exists).
  • Link the PR and Commit message to the bug using

In general:

  • Keep your PRs focused on a single topic.
  • It is fine if there are multiple commits in a PR, but they must all be related to a single issue and then be squashed into a single commit when merged to master.
  • Remember to Sign the DCO in the PR
    • You will be automatically asked this the first time you contribute to this project via a PR comment.

Development Environment

pre-requisites

  • pnpm >= 8
  • An LTS version of node.js
    • This package is targeted and tested on modern/supported versions of node.js only.

Initial Setup

The initial setup is trivial:

  • clone this repo
  • pnpm i

Committing Changes

This project enforces Angular style commit message conventions using a pre-commit hook.

Formatting.

Prettier is used to ensure consistent code formatting in this repository. This is normally transparent as it automatically activated in a pre-commit hook using lint-staged. However this does mean that dev flows that do not use a full dev env (e.g editing directly on github) may result in voter failures due to formatting errors.

Testing

Mocha is used for unit-testing and Istanbul/Nyc for coverage reports. Jest was avoided due to increased total tests execution time due to running the tests in multiple processes, as the Parser initialization (which happens once per process) can take 10-20ms.

  • To run the tests run pnpm test in a specific subpackage.

Test Coverage

100%* Test Coverage is enforced for all productive code in this mono repo.

  • Specific statements/functions may be excluded from the report but the reason for that must specified in the source code.

Full Build

This project does not use any compilation step (Babel/TypeScript), this means that the full build does not generate any artifacts for runtime.

  • To run the full Continuous Integration build run pnpm ci in in either the top level package or a specific subpackage.

Release Life-Cycle.

This monorepo uses Lerna's fixed / locked mode and automatically generates the changelog by adhering to Conventional Commits

Release Process

Performing a release requires push permissions to this repository.

  • Ensure you are on master branch and synced with origin.
  • pnpm run release:version
  • Follow the lerna CLI instructions.
  • Track the release build on github actions
  • Once the release build has finished successfully inspect the npm registry to see the new versions for all the changed packages of this mono-repo.
    • npm view [package-name] version