Skip to content

Latest commit

 

History

History
148 lines (100 loc) · 5.36 KB

CONTRIBUTING.md

File metadata and controls

148 lines (100 loc) · 5.36 KB
Raw

Welcome 💖

Before anything else, thank you for taking some of your precious time to help this project move forward. ❤️

If you're new to open source and feeling a bit nervous 😳, we understand! We recommend watching this excellent guide to give you a grounding in some of the basic concepts. We want you to feel safe to make mistakes, and ask questions.

If anything in this guide or anywhere else in the codebase doesn't make sense to you, please let us know! It's through your feedback that we can make this codebase more welcoming, so we'll be glad to hear thoughts.

You can chat with us in the #committers-js channel in our Community Slack, or feel free to raise an issue if you're experiencing any friction trying make your contribution.

Setup

  • install Node.Js
  • npm install - Install dependencies
  • npm test - Compile typescript and run the tests

Tests

Now type npm run or see the package.json scripts section for how to run each category of tests.

Internals

Project Structure

└── src
    │
    ├── cli                   # argv parsing, reading files
    │
    ├── formatter             # displaying the results
    │
    ├── models                # data structures
    │
    ├── runtime               # run test cases, emits the event protocol
    │
    └── support_code_library  # load hooks / step definitions

The runtime emits events with an EventEmitter

Coding style

  • Promises and ES7 async/await
  • Try to make things as unit testable as possible. If it's hard to unit test, the class/function may be doing too much.

Changelog

  • Every PR should have a changelog entry
  • The contributor should update the changelog
  • Each entry in the changelog should include a link to the relevant issues/PRs

Release process

The following is a checklist for maintainers when preparing a new release

Major releases

We will always make a release candidate before issuing a major release. The release candidate will be available for at least a month to give users time to validate that there are no unexpected breaking changes.

Process

The release is done from the cucumber-build docker container. This makes sure we use the same environment for all releases.

Every command should be run from within the Docker container.

Start the container:

make docker-run

Inside the container, install the correct version of Node:

nvm install --lts

Then update the dependencies and test:

npm run update-dependencies
npm run
npm run test

If the tests fail, update your code to be compatible with the new libraries, or revert the library upgrades that break the build.

  • Add missing entries to CHANGELOG.md
    • Ideally the CHANGELOG should be up-to-date, but sometimes there will be accidental omissions when merging PRs. Missing PRs should be added.
    • Describe the major changes introduced. API changes must be documented. In particular, backward-incompatible changes must be well explained, with examples when possible.
    • git log --format=format:"* %s (%an)" --reverse <last-version-tag>..HEAD might be handy.
  • Update the contributors list in package.json
    • git log --format=format:"%an <%ae>" --reverse <last-version-tag>..HEAD | grep -vEi "(renovate|dependabot|Snyk)" | sort| uniq -i
    • Manually add contributors (in alphabetical order)

Decide what the next version should be.

Update CHANGELOG links:

NEW_VERSION=<major.minor.patch(-rc.X)> make update-changelog

Verify changes to the CHANGELOG are correct. Stage uncommitted changes:

git add .
git commit -am "Release <major.minor.patch(-rc.X)>"

Then bump the version number and create a git tag. Run one of the following:

# Major prelease
npm version premajor --preid=rc

# Major release
npm version major

# Minor release
npm version minor

# Patch release
npm version patch

Publish to npm:

npm publish --access public

Push to git:

git push
git push --tags