Hi there, thanks for checking out our repo!
seek-datadog-custom-metrics defines a common interface for sending Datadog custom metrics from Node.js runtime environments. It's a general-purpose package, so third-party contributions are more than welcome.
SEEKers: this repo is public, so don't commit or post anything that isn't ready for the entire world to see.
seek-datadog-custom-metrics is documented through its README. We maintain release notes on GitHub, and distribute it as an npm package.
Submit an issue if you have a question, feature request or bug report.
If you work at SEEK, #typescriptification is your friend.
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.
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
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/datadog-custom-metrics.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.
You may find it easier to develop alongside unit tests:
yarn test --watch
Format your code once you're happy with it:
yarn format
We run linting and testing in CI, but consider running these commands locally for a faster feedback loop:
yarn lint
yarn test
Consider whether you are making a visible change to the public seek-datadog-custom-metrics interface, which includes:
- Top-level exports from src/index.ts
- npm dependencies
A release is not necessary for:
- Documentation like the README
- Internal refactoring that preserves the existing interface
- 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 functionalityfix(scope): Squash a bug
-
Minor release
0.X.0
: new, backwards-compatible functionalityfeat(scope): Add a feature
-
Major release
X.0.0
: backwards-incompatible modificationfix(scope): Close security holes BREAKING CHANGE: We deleted all our code.
Note that the
fix
type could be anything; theBREAKING CHANGE:
prefix in the commit body is what determines the release as major.
Specifying a scope makes it easy to eyeball which part of seek-datadog-custom-metrics a change relates to:
chore(docs): Update README
fix(CloudWatchClient): Improve tag sanitisation
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.
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.