Build and Release Process
Relevant source files
The following files were used as context for generating this wiki page:
The data-path project employs a modern, automated build and release pipeline designed for a zero-dependency TypeScript environment. The process focuses on strict type safety, consistent code styling via Biome, and automated versioning through Conventional Commits and GitHub Actions.
The workflow is structured to ensure that every contribution is linted, tested, and properly formatted before being merged into the main branch. Once merged, the release process is handled automatically, removing the need for manual version bumping or changelog generation.
Development and Build Workflow
Local development is centered around a simple "install and build" philosophy. The project uses tsup as the primary bundler to generate multiple distribution formats (CommonJS and ESM) while maintaining type definitions.
Build Tools and Scripts
The build process is defined within package.json using the following core scripts:
| Script | Command | Description |
|---|---|---|
build | tsup src/index.ts --format cjs,esm --dts --clean | Compiles source to CJS/ESM and generates .d.ts files. |
dev | npm run build -- --watch | Activates tsup's watch mode for instant rebuilding during development. |
typecheck | tsc --noEmit | Validates TypeScript types without generating output files. |
lint | biome check src | Runs the Biome linter and formatter check. |
test | vitest run --typecheck | Executes the test suite and performs type-level testing. |
Sources: package.json:13-22, CONTRIBUTING.md:25-32
Local Execution Flow
The following diagram illustrates the typical developer workflow from setup to local verification:
The npm run dev command utilizes tsup to watch for file changes and instantly rebuild the project, which is particularly useful for testing the MCP server implementation.
Sources: CONTRIBUTING.md:23-35, package.json:14-15
Quality Control and Linting
The project enforces code quality through Biome, a tool that handles both linting and formatting without complex configuration files.
Biome Configuration
The biome.json file specifies the project's adherence to recommended rules, with minor adjustments for complexity (e.g., allowing arrow functions).
- Formatter: Uses tabs for indentation and double quotes for JavaScript strings.
- Linter: Enables recommended rules and ensures imports are organized automatically.
- VCS Integration: Linked to Git to respect
.gitignorefiles.
Sources: biome.json:1-38, CONTRIBUTING.md:37-41
Git Hooks
Husky is utilized to trigger a pre-commit hook that runs Biome. This ensures that any code committed to the repository is automatically formatted and free of basic linting errors.
Sources: CONTRIBUTING.md:43-46, package.json:20
Release and Publishing Process
data-path uses an automated release system where the versioning and changelog generation are entirely driven by commit history.
Conventional Commits
All commits must follow the Conventional Commits specification. This is enforced by commitlint and a pre-commit hook. The type of commit determines the scope of the automated version bump:
| Commit Type | Release Type | Example |
|---|---|---|
feat | Minor (e.g., 1.0.0 -> 1.1.0) | feat: added a new tool |
fix | Patch (e.g., 1.0.0 -> 1.0.1) | fix: resolved crash |
docs / chore | No Release | docs: updated readme |
Sources: CONTRIBUTING.md:52-59, commitlint.config.js:1
CI/CD Pipeline
The release pipeline is triggered upon merging a Pull Request into the main branch.
GitHub Actions manages the compilation, testing, and execution of semantic-release. Once the checks pass, the package is published to the NPM registry. The files included in the final package are restricted to the dist directory.
Sources: CONTRIBUTING.md:63-66, package.json:8-11, 44-48
Conclusion
The build and release process of data-path is designed to be low-friction for contributors while maintaining high standards for the published package. By leveraging Biome for zero-config styling and Semantic Release for automated versioning, the project ensures that the main branch is always in a deployable state and that NPM releases accurately reflect the changes introduced by the community.