Publishing and CI/CD
Relevant source files
The following files were used as context for generating this wiki page:
The playwright-page-object project employs an automated pipeline for code quality, testing, and distribution. The system relies on strict commit conventions to drive versioning and utilizes GitHub Actions for continuous integration and automated publishing to the NPM registry.
Sources: CONTRIBUTING.md:43-52, package.json:49-76
Code Quality and Linting
The project uses Biome as an all-in-one tool for formatting and linting. It is configured to run automatically during the development cycle to ensure consistency across the codebase without requiring manual editor configuration.
Linting Configuration
Biome is configured to use tabs for indentation and double quotes for JavaScript strings. It enables recommended linting rules while specifically disabling the requirement for arrow functions in certain complexity contexts.
Sources: biome.json:11-25, CONTRIBUTING.md:28-35
Git Hooks
Husky is integrated to manage pre-commit hooks. Before a commit is finalized, the system automatically runs linting and formatting fixes to prevent malformed code from entering the repository.
# Manual linting and fixing
npm run lint:fix
Sources: package.json:16, CONTRIBUTING.md:33-40
Commit Standards and Versioning
The project enforces Conventional Commits via commitlint. These commit messages are critical because they programmatically determine the next version number and generate the changelog during the release process.
Commit Types and Impact
The following table describes how specific commit prefixes affect the automated versioning system:
| Commit Prefix | Description | Release Type |
|---|---|---|
feat: | Introduction of a new tool or feature | Minor (e.g., 1.1.0) |
fix: | Resolution of a bug or crash | Patch (e.g., 1.0.1) |
docs: | Updates to documentation | No Release |
chore(release): | Automated release commit | Internal |
Sources: CONTRIBUTING.md:44-50, package.json:59-69, commitlint.config.js:1
Continuous Integration (CI)
The CI pipeline, triggered on pull requests and merges to the main branch, executes a series of validation steps.
Automated Testing
The project utilizes vitest for unit tests and Playwright for end-to-end (E2E) testing of example applications. In CI environments, the Playwright configuration is adjusted for stability:
- Parallelism: Tests run in parallel.
- Workers: Restricted to 1 worker in CI to prevent resource contention.
- Retries: Configured for 2 retries in CI (0 in local development).
- WebServer: Starts the local dev server and waits for it to be available.
Sources: example/playwright.config.ts:5-23, package.json:19-21
CI Pipeline Flow
This diagram illustrates the lifecycle of a contribution from local development to the final package release.
The flow shows how automated checks ensure code quality before a release is triggered by a merge to the main branch.
Sources: CONTRIBUTING.md:31-52, package.json:11-21, example/playwright.config.ts:1-23
Automated Publishing
Publishing is handled by semantic-release. Once code is merged into the main branch, GitHub Actions executes the release plugin suite.
Release Plugins and Assets
The release process is configured with the following plugins in package.json:
- @semantic-release/commit-analyzer: Analyzes commit messages to determine the version bump.
- @semantic-release/release-notes-generator: Generates changelogs.
- @semantic-release/npm: Handles the actual publishing to the NPM registry.
- @semantic-release/git: Commits updated version numbers in
package.jsonandpackage-lock.jsonback to the repository with a[skip ci]tag to prevent loops. - @semantic-release/github: Creates a GitHub release with the generated notes.
Sources: package.json:49-76, CONTRIBUTING.md:52-54
Build Artifacts
Before publishing, the project is compiled using tsup. The build target produces:
- CommonJS:
./dist/index.js - ES Modules:
./dist/index.mjs - Type Definitions:
./dist/index.d.ts
Sources: package.json:7-13
Summary
The project maintains a high level of automation where developers focus on code and conventional commit messages, while the CI/CD infrastructure handles linting, cross-environment testing, versioning, and distribution. This ensures that the published NPM package always reflects a stable, tested, and correctly versioned state of the main branch.