CONTRIBUTING.md

Contributing

Hi there, thanks for checking out our repo!

eslint-config-skuba is a shareable ESLint config for skuba, our toolkit for developing TypeScript backend applications and packages at SEEK. While third-party contributions are certainly welcome, this project is primarily driven by our internal priorities and technology strategy.

SEEKers: this repo is public, so don't commit or post anything that isn't ready for the entire world to see.

Table of contents

• Getting started
  • I want to discuss or report something
  • I want to contribute a change
• Development
  • Prerequisites
  • Git workflow
  • Testing
• Releases
  • Creating a changeset
  • Publishing a release
  • Publishing a prerelease

Getting started

eslint-config-skuba is documented through its README. We maintain release notes on GitHub, and distribute it as an npm package.

I want to discuss or report something

Submit an issue if you have a question, feature request or bug report.

If you work at SEEK, #typescriptification is your friend.

I want to contribute a change

Feel free to create a pull request for trivial fixes and improvements.

For more substantial features, please submit an issue first. This lets us evaluate whether the feature fits the direction of the project and discuss possible approaches.

Development

Prerequisites

We depend on upstream tooling like skuba that are predominantly tested on macOS and Linux. If you're on Windows, we recommend the Windows Subsystem for Linux.

First, some JavaScript tooling:

• Node.js 12+
• Yarn 1.x

Next, install npm dependencies:

yarn install

Git workflow

We use GitHub flow.

Create a new branch off of the latest commit on master:

git fetch origin
git switch --create your-branch-name origin/master

Develop, test and commit your changes on this branch. (Make sure to use a semantic commit message.)

git add --all
git commit

Finally, push your branch to GitHub and create a pull request:

git push --set-upstream origin your-branch-name

If you don't have push access, you may need to fork the repo and push there instead:

git remote add fork git@github.com:your-username/eslint-config-skuba.git
git push --set-upstream fork your-branch-name

A maintainer will get to your pull request and review the changes. If all is well, they will merge your pull request into master.

Testing

The easiest way to test your changes is to try them out on an actual project. Find or create a repo using skuba, then specify your changes as extensions to the stable eslint-config-skuba release:

module.exports = {
  extends: ['skuba'],

  // your changes here
  overrides: {},
  rules: {},
};

You can then copy those changes back into index.js. Format your code once you're happy with it:

yarn format

We run linting in CI, but consider running this command locally for a faster feedback loop:

yarn lint

Releases

Writing a semantic commit message

Consider whether you are making a visible change to the public eslint-config-skuba interface, which includes:

• Top-level exports from index.js
• npm dependencies

A release is not necessary for:

• Documentation like the README
• npm dev dependencies

We use semantic-release to manage package releases. Commits should follow the Conventional Commits spec for semantic versioning:

• No release

  chore(scope): Update documentation
  

• Patch release 0.0.X: fixes or tweaks to existing functionality

  fix(scope): Squash a bug
  

• Minor release 0.X.0: new, backwards-compatible functionality

  feat(scope): Add a feature
  

• Major release X.0.0: backwards-incompatible modification

  fix(scope): Close security holes
  
  BREAKING CHANGE: We deleted all our code.
  

  Note that the fix type could be anything; the BREAKING CHANGE: prefix in the commit body is what determines the release as major.

Specifying a scope makes it easy to eyeball which part of eslint-config-skuba a change relates to:

chore(docs): Update README

fix(jest): Disable expect-expect rule

Publishing a release

When a pull request is merged, our release GitHub Actions workflow will publish the associated GitHub release and npm package version.

We squash our commits, so the merged commit itself needs to have a semantic commit message.

Publishing a prerelease

We currently have limited support for prereleases on the beta dist-tag. This can only be performed by a maintainer.

Simply push changes to the beta branch on GitHub.