eslint-plugin-traceability 1.1.0 → 1.1.2

package/docs/decisions/003-code-quality-ratcheting-plan.md

@@ -1,48 +0,0 @@
----
-status: "accepted"
-date: 2025-11-16
-decision-makers: [Development Team]
-consulted: [Implementation Plan, ESLint Documentation]
-informed: [All Contributors]
----
-
-# 003-Code Quality Ratcheting Plan
-
-## Context and Decision Drivers
-
-The project currently enforces maintainability through ESLint `max-lines-per-function` and `max-lines` rules with thresholds set to 200 lines/function and 1000 lines/file. These loose thresholds present technical debt and allow overly large functions and files, which can hinder readability, maintainability, and increase complexity over time.
-
-## Considered Options
-
-1. Adopt strict industry-standard thresholds immediately (e.g., 100 lines/function, 500 lines/file).
-2. Maintain the current loose thresholds indefinitely.
-3. Implement an incremental ratcheting plan to gradually reduce thresholds over multiple sprints.
-
-## Decision Outcome
-
-We will implement option 3: an incremental ratcheting plan to gradually reduce the ESLint thresholds:
-
-- **Sprint 0 (Now)**: Reduce `max-lines-per-function` to 150 and `max-lines` to 800.
-- **Sprint 2 (Completed 2025-11-16)**: Reduce `max-lines-per-function` to 120 and `max-lines` to 600.
-- **Sprint 4**: Reduce `max-lines-per-function` to 100 and `max-lines` to 500.
-
-Automation:
-
-- Update the ESLint configuration to enforce the new thresholds immediately.
-- Configure the CI pipeline to fail on any new violations of these rules.
-- Document the ratcheting schedule in this ADR and revisit the plan at each milestone.
-
-## Consequences
-
-- Ensures maintainability improves in manageable increments, reducing developer overhead per sprint.
-- Provides clear visibility into the schedule and expectations for code size reductions.
-- Allows refactoring efforts to be planned and executed incrementally, avoiding large-scale rewrites.
-- Guarantees continuous improvement by automating enforcement in CI.
-
-## Future Review
-
-At the end of each milestone sprint, the team will:
-
-- Review existing violations.
-- Refactor code to comply with the new thresholds.
-- Update this ADR if any adjustments to the schedule are required.

package/docs/decisions/004-automated-version-bumping-for-ci-cd.md

@@ -1,196 +0,0 @@
----
-status: "superseded"
-date: 2025-11-17
-decision-makers: [Development Team]
-consulted:
-  [
-    npm Documentation,
-    GitHub Actions Best Practices,
-    Semantic Versioning Specification,
-  ]
-informed: [Project Stakeholders, CI/CD Pipeline Maintainers]
-superseded-by: "006-semantic-release-for-automated-publishing"
-superseded-date: "2025-11-17"
----
-
-# Automated Version Bumping for CI/CD Publishing
-
-## Context and Problem Statement
-
-The current CI/CD pipeline attempts to publish the package to npm on every push to the main branch, but lacks any mechanism to automatically increment the package version. This causes publish failures when the same version number already exists on npm, as npm does not allow republishing the same version. The pipeline fails with errors like "You cannot publish over the previously published versions" or similar npm publish conflicts.
-
-Currently, version bumping requires manual intervention through direct package.json edits, which is error-prone, interrupts the automated delivery flow, and creates a disconnect between the continuous integration process and package publishing. This breaks the principle of continuous delivery and creates friction in the development workflow.
-
-## Decision Drivers
-
-- Need for reliable automated publishing without manual intervention
-- Prevention of npm publish failures due to version conflicts
-- Alignment with semantic versioning principles for clear change communication
-- Integration with existing CI/CD pipeline and GitHub workflow
-- Maintainability of version history and changelog automation
-- Support for different types of releases (patch, minor, major)
-- Traceability of version changes to specific commits or pull requests
-- Minimal friction for developers while maintaining version discipline
-
-## Considered Options
-
-- npm version command with automated execution in CI/CD
-- Semantic Release with automated version detection
-- Manual version bumping with CI/CD workflow triggers
-- Version bumping through GitHub Actions with npm version
-
-## Decision Outcome
-
-Chosen option: "Version Increment Without Git Commits", because it eliminates CI/CD loop complexity, requires no git write permissions, solves the immediate npm publish failures, and provides the simplest implementation while maintaining full automation.
-
-### Implementation Strategy
-
-The CI/CD pipeline will use in-memory version increments without git write-back:
-
-1. **Pre-publish Version Check**: Before attempting to publish, check if the current package.json version already exists on npm using `npm view eslint-plugin-traceability@<version>`
-2. **In-Memory Version Increment**: If the version exists on npm, increment the patch version in the pipeline workspace using `npm version patch --no-git-tag-version`
-3. **Immediate Publish**: Proceed with npm publish using the incremented version without any git operations
-4. **Pipeline Logging**: Log the version increment action for visibility and debugging
-5. **No Git Write-Back**: The incremented version exists only in the pipeline workspace and is never committed back to the repository
-
-### Primary Approach Considered
-
-**Git Write-Back with Version Commits**: Increment version in pipeline, publish to npm, then commit version changes and create git tags with `[skip ci]` to prevent recursion. This approach was rejected due to complexity concerns including git write permissions, infinite loop prevention, post-publish failure handling, and potential race conditions in concurrent pipeline runs.
-
-### Consequences
-
-- Good, because prevents all npm publish failures due to version conflicts
-- Good, because maintains fully automated delivery without any manual intervention
-- Good, because eliminates infinite CI/CD loop risks entirely
-- Good, because requires no git write permissions or credentials in CI/CD
-- Good, because uses standard npm tooling that developers understand
-- Good, because simplest possible implementation with minimal failure modes
-- Good, because each pipeline run is completely independent
-- Good, because immediate resolution to publish failures with no complexity overhead
-- Neutral, because package.json version may lag behind published npm version
-- Neutral, because developers can check published version via `npm view eslint-plugin-traceability version`
-- Bad, because does not automatically determine semantic version type (major/minor/patch)
-- Bad, because no automatic git tags or version history created
-
-### Confirmation
-
-Implementation compliance will be confirmed through:
-
-- CI/CD pipeline successfully publishes without version conflicts
-- No npm publish failures due to existing version numbers
-- No git write operations or credentials required in CI/CD
-- No infinite pipeline loops or `[skip ci]` complexity needed
-- Pipeline logs clearly show when version increments occur
-- Published npm versions can be verified via `npm view eslint-plugin-traceability versions`
-- No manual intervention required for routine publishing
-
-## Pros and Cons of the Options
-
-### Version Increment Without Git Commits
-
-In-memory version increments during pipeline execution without any git write-back operations.
-
-- Good, because eliminates all CI/CD loop complexity and infinite recursion risks
-- Good, because requires no git write permissions or credentials in CI/CD environment
-- Good, because simplest possible implementation with minimal failure modes
-- Good, because each pipeline run is completely independent with no race conditions
-- Good, because immediate resolution to npm publish failures
-- Good, because uses standard npm version tooling familiar to developers
-- Good, because no complex error handling for git operations required
-- Neutral, because package.json version may not reflect latest published version
-- Neutral, because published version always discoverable via npm registry
-- Bad, because no automatic git tags created for release tracking
-- Bad, because requires manual version management for major/minor releases
-- Bad, because no automated version commit history
-
-### Git Write-Back with Version Commits
-
-Increment version in pipeline, publish to npm, then commit version changes and create git tags.
-
-- Good, because creates proper git tags and version commits automatically
-- Good, because maintains package.json synchronization with published versions
-- Good, because provides complete version history in git repository
-- Good, because allows for automated CHANGELOG.md updates
-- Good, because follows traditional npm ecosystem patterns
-- Neutral, because requires configuration of git credentials in CI/CD
-- Neutral, because creates automated commits with CI skip directives
-- Bad, because requires complex infinite loop prevention with `[skip ci]`
-- Bad, because potential for git write failures after successful npm publish
-- Bad, because introduces race conditions in concurrent pipeline runs
-- Bad, because requires git write permissions and credential management
-- Bad, because adds multiple failure modes beyond the core publish operation
-
-### Semantic Release with automated version detection
-
-Automated semantic versioning based on commit message analysis and release automation.
-
-- Good, because fully automated semantic version determination
-- Good, because analyzes commit messages for version type
-- Good, because comprehensive release note generation
-- Good, because follows semantic versioning specification strictly
-- Good, because popular in open source ecosystem
-- Neutral, because requires standardized commit message format
-- Bad, because adds significant complexity to CI/CD pipeline
-- Bad, because requires team discipline for commit message formatting
-- Bad, because may be overkill for the current project size
-- Bad, because introduces external dependency on semantic-release tool
-- Bad, because harder to override for exceptional cases
-
-### Manual version bumping with CI/CD workflow triggers
-
-Requiring manual version increments before publishing with workflow validation.
-
-- Good, because provides full developer control over versioning
-- Good, because ensures deliberate version decisions
-- Good, because no automated commits or git history noise
-- Good, because simple to understand and implement
-- Neutral, because requires developer discipline for version management
-- Bad, because breaks continuous delivery principle
-- Bad, because requires manual intervention for every release
-- Bad, because prone to human error and forgotten version bumps
-- Bad, because does not solve the original npm publish failure problem
-- Bad, because creates friction in development workflow
-
-## More Information
-
-This decision addresses the immediate CI/CD publish failures with the simplest possible solution that eliminates complexity while maintaining full automation. The in-memory version increment approach provides immediate relief from npm publish conflicts without introducing git write-back complexity.
-
-Key implementation details:
-
-```yaml
-- name: Prepare version for publish
-  run: |
-    CURRENT_VERSION=$(node -p "require('./package.json').version")
-    echo "Current package.json version: $CURRENT_VERSION"
-
-    # Check if this version exists on npm
-    if npm view eslint-plugin-traceability@$CURRENT_VERSION version >/dev/null 2>&1; then
-      echo "Version $CURRENT_VERSION already exists on npm, incrementing..."
-      npm version patch --no-git-tag-version
-      NEW_VERSION=$(node -p "require('./package.json').version")
-      echo "Bumped version to: $NEW_VERSION"
-    else
-      echo "Version $CURRENT_VERSION is available, proceeding with publish"
-    fi
-
-- name: Publish package
-  run: npm publish --access public
-```
-
-Implementation considerations:
-
-- No git credentials or write permissions required in CI/CD
-- Version increments are logged for visibility and debugging
-- Each pipeline run operates independently with no side effects
-- Published versions remain discoverable via `npm view eslint-plugin-traceability versions`
-- Manual version bumps for major/minor releases can still be done via git commits
-- Future migration to git write-back approach remains possible if needed
-
-This decision should be re-evaluated if:
-
-- Package.json/npm version drift becomes problematic for development workflow
-- Automatic git tagging becomes a requirement for release management
-- The team adopts semantic versioning discipline requiring commit message analysis
-- Integration with automated changelog generation becomes necessary
-
-The simplicity of this approach allows for easy migration to more complex solutions later while solving the immediate problem with minimal risk and complexity.

package/docs/decisions/005-github-actions-validation-tooling.accepted.md

@@ -1,144 +0,0 @@
----
-status: "accepted"
-date: 2025-11-17
-decision-makers: [Development Team]
-consulted:
-  [
-    GitHub Actions Documentation,
-    Super-Linter Community,
-    actionlint Documentation,
-  ]
-informed: [Project Contributors, CI/CD Pipeline Maintainers]
----
-
-# GitHub Actions Validation Tooling Selection
-
-## Context and Problem Statement
-
-The project uses GitHub Actions for CI/CD workflows defined in `.github/workflows/`. To prevent broken GitHub Actions files from being pushed to the repository, we need to implement pre-commit validation for GitHub Actions YAML files. This validation should catch syntax errors, invalid action references, and misconfigured job dependencies before they are committed, as broken workflow files could prevent CI/CD from running at all.
-
-## Decision Drivers
-
-- Need for pre-commit validation to prevent broken GitHub Actions files from being pushed
-- Performance requirements for fast local development workflows
-- Prevention of workflow files that would break CI/CD execution
-- Integration with existing development tools and pre-commit hooks
-- Maintainability and configuration simplicity
-- Resource efficiency for local development environments
-
-## Considered Options
-
-- actionlint for pre-commit hooks only
-- actionlint for both pre-commit and CI/CD
-- Super-Linter for pre-commit hooks
-- GitHub's built-in validation only
-
-## Decision Outcome
-
-Chosen option: "actionlint for pre-commit hooks only", because it prevents broken GitHub Actions files from being pushed while maintaining fast local development workflow. Once files reach CI/CD, if the workflow runs successfully, the files are valid by definition.
-
-### Consequences
-
-- Good, because actionlint provides fast pre-commit validation without container overhead
-- Good, because prevents broken GitHub Actions files from being pushed
-- Good, because specifically designed for GitHub Actions validation
-- Good, because simple configuration and maintenance
-- Good, because no Docker dependencies for local development
-- Good, because excellent performance for pre-commit hooks
-- Good, because integrates seamlessly with existing Husky-based pre-commit hooks
-- Neutral, because CI/CD validation is unnecessary if workflows execute successfully
-- Bad, because limited to GitHub Actions validation only
-- Bad, because no security vulnerability detection in pre-commit phase
-
-### Confirmation
-
-Implementation compliance will be confirmed through:
-
-- actionlint added to Husky pre-commit hook in `.husky/pre-commit`
-- Pre-commit hook blocks commits with GitHub Actions validation errors
-- actionlint configured to validate files in `.github/workflows/`
-- Documentation updated to explain Husky-based pre-commit validation approach
-
-### Implementation Approach
-
-actionlint will be integrated into existing Husky-based pre-commit hooks by:
-
-- Installing actionlint as a development dependency
-- Adding actionlint validation to `.husky/pre-commit` hook
-- Configuring actionlint to check `.github/workflows/*.yml` files
-- Documenting the validation process for contributors
-
-## Pros and Cons of the Options
-
-### actionlint for pre-commit hooks only
-
-Lightweight, focused pre-commit validation to prevent broken GitHub Actions files.
-
-- Good, because fast execution without container overhead
-- Good, because specifically designed for GitHub Actions validation
-- Good, because no Docker dependencies for local development
-- Good, because simple configuration and maintenance
-- Good, because excellent performance for pre-commit hooks
-- Good, because prevents broken workflow files from being pushed
-- Good, because minimal tooling - only runs where validation is needed
-- Neutral, because focused scope reduces complexity
-- Neutral, because CI/CD validation unnecessary if workflows execute successfully
-- Bad, because limited to GitHub Actions validation only
-- Bad, because no security vulnerability detection in pre-commit phase
-
-### actionlint for both pre-commit and CI/CD
-
-Validation in both development and CI/CD environments.
-
-- Good, because fast execution in all environments
-- Good, because specifically designed for GitHub Actions
-- Good, because consistent validation across environments
-- Neutral, because focused scope reduces complexity
-- Bad, because unnecessary duplication - CI/CD execution validates workflow correctness
-- Bad, because adds CI/CD overhead for validation that's already proven by execution
-- Bad, because limited to GitHub Actions validation only
-
-### Super-Linter for pre-commit hooks
-
-Comprehensive linting solution for pre-commit validation.
-
-- Good, because comprehensive validation including security checks
-- Good, because validates multiple file types beyond GitHub Actions
-- Neutral, because well-maintained and widely adopted
-- Bad, because container overhead makes pre-commit hooks slow
-- Bad, because heavy resource usage for simple syntax checking
-- Bad, because Docker dependency required for local development
-- Bad, because not optimized for frequent pre-commit execution
-- Bad, because overkill for the specific problem of preventing broken workflow files
-
-### GitHub's built-in validation only
-
-Rely solely on GitHub's native workflow validation.
-
-- Good, because no additional tooling or configuration required
-- Good, because automatically available in GitHub interface
-- Good, because validated by the same system that executes workflows
-- Neutral, because basic validation is always performed
-- Bad, because no pre-commit validation for early error detection
-- Bad, because broken files can be pushed, preventing CI/CD execution
-- Bad, because errors only discovered after push to repository
-- Bad, because no local development feedback
-
-## More Information
-
-This decision focuses on solving the specific problem of preventing broken GitHub Actions files from being pushed to the repository. If CI/CD workflows execute successfully, the files are validated by definition - there's no need for redundant validation in the CI/CD pipeline itself.
-
-actionlint configuration should be added to the existing Husky pre-commit hook in `.husky/pre-commit`, targeting `.github/workflows/*.yml` files to catch syntax and configuration errors before commit.
-
-The decision should be re-evaluated if:
-
-- Security vulnerability detection becomes a requirement for pre-commit validation
-- Comprehensive multi-language linting becomes necessary for pre-commit
-- Alternative tools with better GitHub Actions-specific features emerge
-- The problem scope expands beyond preventing broken workflow files
-
-Related resources:
-
-- [actionlint Documentation](https://github.com/rhymond/actionlint)
-- [GitHub Actions Workflow Syntax](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions)
-- [Husky Documentation](https://typicode.github.io/husky/)

package/docs/decisions/006-semantic-release-for-automated-publishing.accepted.md

@@ -1,227 +0,0 @@
----
-status: "accepted"
-date: 2025-11-17
-decision-makers: [Development Team]
-consulted:
-  [
-    semantic-release Documentation,
-    Conventional Commits Specification,
-    GitHub Actions Best Practices,
-    npm Publishing Guidelines,
-  ]
-informed: [Project Stakeholders, CI/CD Pipeline Maintainers]
----
-
-# Semantic Release for Automated Publishing
-
-## Context and Problem Statement
-
-The current automated version bumping strategy (ADR 004) has several limitations that impact maintainability and developer experience:
-
-1. **Single Increment Logic**: The CI/CD pipeline only increments the version once, requiring complex loop logic to handle cases where multiple increments are needed (e.g., when both 1.0.3 and 1.0.4 already exist on npm)
-
-2. **No Semantic Version Determination**: The system only performs patch increments and cannot automatically determine when minor or major version bumps are appropriate based on the nature of changes
-
-3. **Missing Release Management**: No automatic git tagging, release notes, or CHANGELOG.md generation, reducing traceability and release visibility
-
-4. **Workflow Complexity**: The custom version increment logic in GitHub Actions is becoming complex and error-prone, potentially violating workflow validation best practices established in ADR 005
-
-5. **Package.json/npm Version Drift**: The package.json version in the repository can lag behind the published npm version, creating confusion about the actual release state
-
-The current approach was designed as a temporary solution to prevent npm publish failures, but its limitations suggest that a more comprehensive release automation strategy is needed.
-
-## Decision Drivers
-
-- Need for proper semantic version determination based on change significance
-- Automatic generation of release notes and changelog maintenance
-- Git tag creation for release tracking and traceability
-- Elimination of complex custom version increment logic in CI/CD workflows
-- Integration with conventional commit standards for automated version type detection
-- Prevention of unnecessary publishing when no changes warrant a release
-- Alignment with npm ecosystem best practices for release management
-- Simplification of GitHub Actions workflow to improve maintainability and validation compliance
-
-## Considered Options
-
-- Enhance current in-memory version increment approach with loop logic
-- Implement semantic-release with conventional commits
-- Switch to git write-back approach with automated tagging
-- Implement manual release workflow with GitHub releases
-
-## Decision Outcome
-
-Chosen option: "semantic-release with conventional commits", because it provides comprehensive release automation, proper semantic versioning, automated changelog generation, and eliminates the need for complex custom version logic while following industry standards.
-
-### Implementation Strategy
-
-1. **Install and Configure semantic-release**:
-   - Add `semantic-release` and related plugins as development dependencies
-   - Configure semantic-release with conventional commits preset
-   - Set up plugins for npm publishing, git tagging, and changelog generation
-
-2. **Establish Conventional Commit Standards**:
-   - Adopt conventional commit message format for semantic version determination
-   - Configure semantic-release to analyze commit messages for version impact
-   - Document commit message guidelines for contributors
-
-3. **Update CI/CD Pipeline**:
-   - Replace custom version increment logic with semantic-release execution
-   - Configure semantic-release to run on main branch pushes
-   - Set up proper npm registry authentication and git permissions
-
-4. **Configure Release Automation**:
-   - Automatic CHANGELOG.md generation and maintenance
-   - Git tag creation for each release
-   - GitHub release creation with release notes
-   - Conditional publishing (only when changes warrant a release)
-
-### Consequences
-
-- Good, because eliminates complex custom version increment logic from CI/CD workflows
-- Good, because provides proper semantic version determination based on commit analysis
-- Good, because automatically generates and maintains CHANGELOG.md with release notes
-- Good, because creates proper git tags and GitHub releases for traceability
-- Good, because follows conventional commits standard adopted widely in open source
-- Good, because only publishes when changes actually warrant a new release
-- Good, because avoids package.json version drift by using git tags as source of truth
-- Good, because simplifies GitHub Actions workflow, improving validation compliance
-- Good, because provides comprehensive release management with minimal configuration
-- Good, because prevents infinite CI loops from version commits
-- Neutral, because requires team adoption of conventional commit message format
-- Neutral, because package.json version in repository may lag behind published version (git tags are source of truth)
-- Bad, because introduces dependency on semantic-release tool and its ecosystem
-- Bad, because may require learning curve for conventional commit message format
-
-### Confirmation
-
-Implementation compliance will be confirmed through:
-
-- semantic-release successfully analyzes commits and determines appropriate version increments
-- Automatic CHANGELOG.md generation and git tag creation on releases
-- CI/CD pipeline publishes to npm only when semantic-release determines a release is warranted
-- No npm publish failures due to version conflicts or unnecessary publishing attempts
-- Package.json version remains synchronized with published npm version
-- GitHub Actions workflow simplified and validates successfully with actionlint (ADR 005)
-- Conventional commit message format adopted and documented for contributors
-
-## Pros and Cons of the Options
-
-### semantic-release with conventional commits
-
-Comprehensive automated release management based on commit message analysis.
-
-- Good, because industry standard tool with extensive ecosystem
-- Good, because proper semantic version determination based on commit analysis
-- Good, because automatic CHANGELOG.md and release notes generation
-- Good, because creates git tags and GitHub releases automatically
-- Good, because only publishes when changes warrant a release
-- Good, because eliminates custom version increment logic complexity
-- Good, because maintains git history and package.json synchronization
-- Good, because follows conventional commits standard
-- Good, because comprehensive documentation and community support
-- Neutral, because requires conventional commit message discipline
-- Neutral, because adds dependency on semantic-release ecosystem
-- Bad, because requires git write permissions in CI/CD
-- Bad, because learning curve for commit message conventions
-
-### Enhanced in-memory version increment with loop logic
-
-Improve the current approach with better version conflict resolution.
-
-- Good, because builds on existing working foundation
-- Good, because no external dependencies or new tooling
-- Good, because maintains current simplicity of git read-only CI/CD
-- Neutral, because addresses immediate technical limitation
-- Bad, because still provides only patch-level version increments
-- Bad, because no semantic version determination capability
-- Bad, because no automatic changelog or git tag generation
-- Bad, because increases complexity of custom GitHub Actions logic
-- Bad, because doesn't address package.json/npm version synchronization
-- Bad, because potential for workflow validation issues with complex logic
-
-### Git write-back approach with automated tagging
-
-Custom solution with git operations for version commits and tagging.
-
-- Good, because provides git tag creation and version history
-- Good, because maintains package.json synchronization
-- Good, because can be customized for specific project needs
-- Neutral, because requires git write permissions
-- Bad, because requires complex infinite loop prevention logic
-- Bad, because no semantic version determination
-- Bad, because no automated changelog generation
-- Bad, because potential race conditions in CI/CD
-- Bad, because increased failure modes with git operations
-- Bad, because custom implementation maintenance burden
-
-### Manual release workflow with GitHub releases
-
-Manual release creation through GitHub interface with automated publishing.
-
-- Good, because provides full control over release timing and messaging
-- Good, because natural integration with GitHub releases interface
-- Good, because allows for manual changelog and release notes
-- Good, because no automated commit message requirements
-- Neutral, because requires manual intervention for releases
-- Bad, because breaks continuous delivery principle
-- Bad, because prone to human error and forgotten releases
-- Bad, because no automation of version determination
-- Bad, because workflow friction for regular development
-- Bad, because doesn't solve original npm publish failure problem
-
-## More Information
-
-This decision supersedes ADR 004 "Automated Version Bumping for CI/CD Publishing", which served as a temporary solution to prevent npm publish failures but has reached its limitations in terms of semantic versioning and release management.
-
-semantic-release configuration will include:
-
-```json
-{
-  "branches": ["main"],
-  "plugins": [
-    "@semantic-release/commit-analyzer",
-    "@semantic-release/release-notes-generator",
-    "@semantic-release/changelog",
-    "@semantic-release/npm",
-    "@semantic-release/github"
-  ]
-}
-```
-
-**Note**: The `@semantic-release/git` plugin is intentionally excluded. semantic-release will manage versions through git tags only, without committing version changes back to package.json. This approach:
-
-- Prevents infinite CI loops from version commits
-- Follows npm ecosystem best practices where tags are the source of truth
-- Keeps the repository history clean of automated version bump commits
-- Aligns with how other projects in the ecosystem use semantic-release
-
-The published npm package will have the correct version, but package.json in the repository may not reflect the latest published version. Git tags serve as the authoritative version record.
-
-Conventional commit format examples:
-
-- `feat: add new validation rule` → minor version increment
-- `fix: resolve annotation parsing issue` → patch version increment
-- `feat!: change API interface` → major version increment
-- `docs: update README` → no version increment
-
-GitHub Actions workflow simplification:
-
-- Remove custom version increment logic
-- Replace with single `npx semantic-release` command
-- Configure necessary permissions (contents:write, issues:write, pull-requests:write, id-token:write)
-- Set HUSKY=0 environment variable to disable git hooks during release
-- Maintain existing quality checks and security audits
-- Add smoke test for published package verification
-
-This decision should be re-evaluated if:
-
-- Conventional commit discipline becomes difficult to maintain
-- semantic-release ecosystem introduces breaking changes or maintenance issues
-- Project requirements change to need custom release logic not supported by semantic-release
-- Team prefers different commit message standards incompatible with conventional commits
-
-Related resources:
-
-- [semantic-release Documentation](https://semantic-release.gitbook.io/)
-- [Conventional Commits Specification](https://www.conventionalcommits.org/)
-- [GitHub Actions with semantic-release](https://github.com/semantic-release/semantic-release/blob/master/docs/recipes/github-actions.md)