Setting Up Changesets and GitHub Actions for CI/CD in a Frontend Monorepo Utility Library

The author introduces a new open‑source frontend utility library called vemjs and explains why establishing a robust contribution process is essential for collaborative development.

1. Using the changeset workflow

Install the Changesets CLI, initialise the configuration, and add the required scripts to package.json :

pnpm i @changesets/cli -Dw

pnpm changeset init

{
  "$schema": "
",
  "changelog": "@changesets/cli/changelog",
  "commit": true,
  "fixed": [],
  "linked": [],
  "access": "public",
  "baseBranch": "main",
  "updateInternalDependencies": "patch",
  "ignore": []
}

"scripts": {
  "change": "changeset add",
  "change:version": "changeset version",
  "release": "pnpm build && pnpm release:only",
  "release:only": "changeset publish"
}

Run pnpm change to create a markdown changeset file, answer the prompts (packages, version bump, description), then execute pnpm change:version to apply the version updates and generate a CHANGELOG.md entry.

Optionally, enhance the changelog with @changesets/changelog-github :

pnpm i @changesets/changelog-github -Dw

{
  ...,
  "changelog": ["@changesets/changelog-github", { "repo": "vmejs/vmejs" }],
  ...
}

Set the GITHUB_TOKEN environment variable (Windows: set GITHUB_TOKEN=YourToken , macOS/Linux: export GITHUB_TOKEN=YourToken ) to allow the GitHub‑based changelog generator to work.

2. CI/CD with GitHub Actions

Create .github/workflows/release.yml to publish on every push to main :

# https://docs.github.com/en/actions/using-workflows/about-workflows
name: Release
on:
  push:
    branches:
      - main
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repo
        uses: actions/checkout@v2
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 16.x
      - name: Setup Pnpm
        uses: pnpm/action-setup@v2
        with:
          version: 7.x
      - name: Install dependencies
        run: pnpm install --no-frozen-lockfile --ignore-scripts
      - name: Create Release Pull Request or Publish to npm
        uses: changesets/action@v1
        with:
          publish: pnpm release
          version: pnpm change:version
          commit: 'chore: version packages'
        env:
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Another workflow .github/workflows/docs-deploy.yml builds the VitePress documentation and pushes it to the gh-pages branch:

name: docs-deploy
on:
  push:
    branches: [main]
jobs:
  docs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: Install pnpm
        uses: pnpm/action-setup@v2
        with:
          version: 7
      - name: Setup Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '16'
          cache: 'pnpm'
      - name: Install dependencies
        run: pnpm install --no-frozen-lockfile --ignore-scripts
      - name: Build vitepress site
        run: pnpm docs:build
        env:
          DOC_ENV: preview
          NODE_OPTIONS: --max-old-space-size=4096
      - name: Deploy to GitHub Pages
        uses: crazy-max/ghaction-github-pages@v2
        env:
          GITHUB_TOKEN: ${{ secrets.ACTION_SECRET }}
        with:
          target_branch: gh-pages
          build_dir: packages/.vitepress/dist

3. Contribution Guide

Prerequisites: Node.js ≥ 16 and PNPM v7. Clone the repository, install dependencies, and create a feature branch (e.g., feature-getDevice ). Implement the function, add unit tests, write documentation, and run the standard scripts ( pnpm dev , pnpm build , pnpm test , pnpm lint , etc.).

Before pushing, generate a changeset ( pnpm change ), then commit following the conventional commit format ( type(scope): subject , e.g., feat(user): add user‑center feature ). Finally, open a Pull Request to main ; after approval, the CI workflow will automatically publish the new version.

4. Project Structure

root
├── docs            # documentation
│   ├── guide
│   └── packages/core/getDevice/index.md
├── packages
│   ├── core        # utility functions (e.g., getDevice)
│   └── shared      # shared helpers
└── playground      # local development sandbox

The core/getDevice package contains index.ts (implementation) and index.test.ts (unit tests).

5. Why Open Source?

Open sourcing the library encourages collaboration, accelerates innovation, and spreads responsibility among contributors. A well‑maintained utility library benefits from many contributors, improves code quality, and reaches a broader audience.

Conclusion

By integrating Changesets, GitHub Actions, and clear contribution guidelines, the project achieves automated versioning, changelog generation, CI testing, and documentation deployment, providing a solid foundation for a sustainable frontend utility library.