Contributing to the Amplitude-TypeScript

May 21, 2026 · View on GitHub

🎉 Thanks for your interest in contributing! 🎉

Getting Started

Create a new issue

If find issues while using this library or just reading through it, look to see if an issue has been created. If no issues are related, feel free to open a new one using the template.

Solve an issue

If you find any existing issues that you are interested in fixing, you are welcome to open a PR and we will gladly review your changes.

Making Changes

Setup locally

Getting setup is quick and easy. Follow the steps below to get your your dev environment up.

  1. Fork GitHub repo
  2. Install dependencies
  3. Build packages
$ git clone <HTTPS_OR_GIT_URL>
$ pnpm install
$ pnpm build

This repo contains mutliple major versions of all packages. For contributions to version 1.x, create a branch off v1.x. For contributions to the 2.x (latest) version, create a branch off main. Refer to the table below for more infomation about the release status of each package.

PackageVersionStatusDev Branch
Browser SDK
@amplitude/analytics-browserV2Betamain
@amplitude/analytics-browserV1Currentv1.x
@amplitude/marketing-analytics-browserV1Currentv1.x
Node SDK
@amplitude/analytics-nodeV2Unreleasedmain
@amplitude/analytics-nodeV1Currentv1.x
ReactNative SDK
@amplitude/analytics-react-nativeV2Unreleasedmain
@amplitude/analytics-react-nativeV1Currentv1.x

Test your changes

Building quality software is one of our top priorities. We recommend getting your changes tested using manual and automated practices.

$ pnpm build
$ pnpm test

When writing commit message, follow PR Commit Title Conventions for the format. A git hook will also run to verify that the format is followed.

Deprecated Packages

The following packages are deprecated and should not be added as dependencies in new code:

  • @amplitude/analytics-types
  • @amplitude/analytics-client-common
  • @amplitude/analytics-remote-config

Replacements:

  • For @amplitude/analytics-types and @amplitude/analytics-client-common: Use @amplitude/analytics-core instead
  • For @amplitude/analytics-remote-config: Use the new remote config client in @amplitude/analytics-core instead

These packages remain in the codebase for backward compatibility with existing code, but new dependencies on them are blocked by CI checks. If your PR fails the "Check Deprecated Packages" CI job, update your package.json to use the appropriate replacement from @amplitude/analytics-core.

Open a PR

Once you are finished with your changes and feel good about the proposed changes, create a pull request. A team member will assist in getting them reviewed. We are excited to work with you on this.

For contributions to version 1.x, open a pull request against v1.x. For contributions to the 2.x (latest) version, open a pull request against main.

Merge

As soon as your changes are approved, a team member will merge your PR to main and will get published shortly after.

Publishing NPM package for the first time

Because the workflow uses Trusted Publishing, a new package can't be published from the publish workflow on the first try.

To publish a package for the first time (administrators only):

  1. run pnpm install from the root
  2. run pnpm deploy:publish:bootstrap and enter the full npm package name (e.g. @amplitude/my-new-package) when prompted. The script publishes an empty package (package.json only); this requires you to be logged into an NPM admin account with 2FA enabled.
  3. navigate to the NPM homepage of the new package
  4. open "Settings" and configure it to use Trusted Publishing
  5. copy the same configuration used in analytics browser. case sensitive
  6. now that it's in NPM and Trusted Publishing is enabled, this package can now be published from workflows

Recovering a partial publish-v2 workflow run

Use this only when a previous Publish v2.x workflow run already created the release version and partially published packages to npm, but the workflow failed before all packages finished publishing.

To recover from that state:

  1. Open the Publish v2.x workflow in GitHub Actions.
  2. Click Run workflow.
  3. Select the same releaseType that the failed run used.
  4. Select the same branch that the failed run used, if applicable.
  5. Enable the skipLernaVersion checkbox.
  6. Run the workflow again.

When skipLernaVersion is enabled, the workflow skips the lerna version step for release and prerelease runs and skips the E2E test step. This lets the workflow continue to the publish step without trying to create a second release version.

Do not use skipLernaVersion for a normal release. It is only intended for recovery after a partial publish-v2 run.

Practices

PR Commit Title Conventions

PR titles should follow conventional commit standards. This helps automate the release process.

Commit Types

  • Special Case: Any commit with BREAKING CHANGES in the body: Creates major release
  • feat(<optional scope>): New features (minimum minor release)
  • fix(<optional scope>): Bug fixes (minimum patch release)
  • perf(<optional scope>): Performance improvement
  • docs(<optional scope>): Documentation updates
  • test(<optional scope>): Test updates
  • refactor(<optional scope>): Code change that neither fixes a bug nor adds a feature
  • style(<optional scope>): Code style changes (e.g. formatting, commas, semi-colons)
  • build(<optional scope>): Changes that affect the build system or external dependencies (e.g. pnpm, Npm)
  • ci(<optional scope>): Changes to our CI configuration files and scripts
  • chore(<optional scope>): Other changes that don't modify src or test files
  • revert(<optional scope>): Revert commit