@eldrforge/kodrdriv 0.0.3 → 0.0.7

package/.kodrdriv/config.yaml

@@ -1,12 +1,20 @@
 verbose: false
-model: gpt-4o
+model: gpt-4.1
 contextDirectories:
-  - .kodrdriv/context/people
-  - .kodrdriv/context/projects
+  - .kodrdriv/context
 commit:
+  add: true
   cached: true
   sendit: true
-  messageLimit: 10
 release:
   from: main
-  to: HEAD
+  to: HEAD
+publish:
+  mergeMethod: squash
+  dependencyUpdatePatterns: ["@theunwalked/*", "@riotprompt/*"]
+  requiredEnvVars: ["NODE_AUTH_TOKEN"]
+link:
+  scopeRoots:
+    "@theunwalked": "../../SemicolonAmbulance"
+    "@riotprompt": "../../StJustReckoning"
+  workspaceFile: "pnpm-workspace.yaml"

package/.kodrdriv/context/content.md

@@ -0,0 +1 @@
+KodrDriv is a tool that is designed to help automate the creation of commit messages and release notes.  It is also a tool that has been designed to support an opinionated approach to organizing related projects and conducting structured releases with Git.   This initial version focuses on pnpm and GitHub, but there are plans to expand coverage over time.

package/README.md

@@ -14,7 +14,7 @@ This will make the `kodrdriv` command available globally on your system.
 
 ## Commands
 
-KodrDriv provides two main commands:
+KodrDriv provides four main commands:
 
 ### Commit Command
 
@@ -53,6 +53,115 @@ kodrdriv release
 > 
 > You can use the `--from` and `--to` options to generate release notes comparing two different releases. For example, to see what changed between v1.0.0 and v1.1.0, you could use `kodrdriv release --from v1.0.0 --to v1.1.0`. This is particularly useful for creating detailed changelogs when preparing release documentation.
 
+### Publish Command
+
+Automate the entire release process, from dependency updates to GitHub release creation:
+
+```bash
+kodrdriv publish
+```
+
+The `publish` command orchestrates a comprehensive release workflow, designed to ensure a safe and consistent release process. Here's what it does:
+
+1.  **Dependency Management**: If a `pnpm-workspace.yaml` file is present, it's temporarily renamed to switch from workspace dependencies to registry versions. It then runs `pnpm update --latest` to ensure dependencies are up to date. You can configure specific dependency patterns to update instead of updating all dependencies using the `dependencyUpdatePatterns` configuration option.
+
+2.  **Pre-flight Checks**: Before committing any changes, it runs the `prepublishOnly` script from your `package.json`. This script should contain your project's pre-flight checks (e.g., `clean`, `lint`, `build`, `test`) to ensure the project is in a good state. **Note**: A `prepublishOnly` script is required in your `package.json` - the publish command will fail if this script is not present.
+
+3.  **Release Commit**: If there are changes to `package.json` or `pnpm-lock.yaml`, it creates an intelligent commit message for the dependency updates.
+
+4.  **Version Bump**: It automatically bumps the patch version of your project.
+
+5.  **Release Notes**: It generates release notes based on the recent changes and saves them to `RELEASE_NOTES.md`.
+
+6.  **Pull Request Automation**:
+    *   It pushes the changes and tags to the origin.
+    *   It creates a new pull request for the release.
+    *   It waits for all status checks on the pull request to pass.
+    *   Once checks are complete, it automatically merges the pull request using the configured merge method (default: squash).
+
+7.  **GitHub Release**: After the PR is merged, it checks out the `main` branch, pulls the latest changes, and creates a new GitHub release with the tag and release notes.
+
+8.  **New Release Branch**: Finally, it creates and pushes a new release branch for the next version (e.g., `release/0.0.5`).
+
+This command is designed for repositories that follow a pull-request-based release workflow with required status checks. It streamlines the process, reducing manual steps and potential for error.
+
+> [!TIP]
+> ### Choosing the Right Merge Method
+> 
+> The merge method you choose affects your Git history and can impact your team's workflow:
+> 
+> - **Squash** (default): Best for keeping a clean, linear history. All commits from the feature branch are combined into a single commit, making it easier to understand what was changed in each release.
+> 
+> - **Merge**: Preserves the complete commit history from the feature branch. Use this when you want to maintain detailed development history and individual commit information.
+> 
+> - **Rebase**: Creates a linear history without merge commits. The commits from the feature branch are replayed on top of the target branch. This keeps history clean while preserving individual commits.
+> 
+> Consider your team's preferences and any branch protection rules when choosing a merge method.
+
+### Link Command
+
+Manage pnpm workspace links for local development with sibling projects:
+
+```bash
+kodrdriv link
+```
+
+The `link` command automates the creation and management of pnpm workspace configurations for local development. It scans your project's dependencies and automatically discovers matching sibling packages in configured scope directories, then updates your `pnpm-workspace.yaml` file to link them for local development.
+
+This is particularly useful when working with monorepos or related packages where you want to use local versions of dependencies instead of published registry versions during development.
+
+**How it works:**
+
+1. **Dependency Analysis**: Reads your `package.json` and examines all dependencies (including devDependencies and peerDependencies)
+
+2. **Scope-based Scanning**: For each configured scope (e.g., `@company`, `@myorg`), it scans the specified root directory to find all available packages by reading their `package.json` files
+
+3. **Smart Matching**: Instead of relying on directory naming conventions, it matches dependencies by their actual package names from `package.json`, handling cases where directory names don't match package names
+
+4. **Workspace Management**: Updates or creates a `pnpm-workspace.yaml` file with the discovered local packages, preserving any existing workspace configuration
+
+**Example Scenario:**
+
+Suppose you're working on `@company/api` and it depends on `@company/logging`. Your directory structure might look like:
+
+```
+workspace/
+├── company-api/          # Contains @company/api
+├── company-logging-lib/  # Contains @company/logging (note: different directory name)
+└── other-project/
+```
+
+The link command would:
+- Scan `../` for packages with scope `@company`
+- Find `@company/logging` in `../company-logging-lib/` 
+- Update `pnpm-workspace.yaml` to include `../company-logging-lib`
+
+**Configuration Requirements:**
+
+The link command requires scope root mappings to be configured. You can provide these via:
+
+1. **Command line**: `--scope-roots '{"@company": "../", "@myorg": "../../"}'`
+2. **Configuration file**: Set `link.scopeRoots` in your `.kodrdriv/config.json`
+
+**Dry Run Support:**
+
+Use `--dry-run` to preview what packages would be linked without making changes:
+
+```bash
+kodrdriv link --scope-roots '{"@company": "../"}' --dry-run
+```
+
+> [!TIP]
+> ### Best Practices for Link Command
+> 
+> - **Use relative paths**: Configure scope roots with relative paths (like `../` or `../../`) to ensure the workspace file works across different environments
+> 
+> - **Scope organization**: Group related packages under the same scope (e.g., `@company/api`, `@company/logging`) for easier management
+> 
+> - **Version with caution**: Consider whether to commit the generated `pnpm-workspace.yaml` file. You might want to add it to `.gitignore` if it's only for local development
+> 
+> - **Multiple scopes**: You can configure multiple scope roots to handle packages from different organizations or teams in the same workspace
+
 ## Command Line Options
 
 KodrDriv provides several command line options to customize its behavior:
@@ -62,6 +171,9 @@ KodrDriv provides several command line options to customize its behavior:
 - `--dry-run`: Perform a dry run without saving files (default: false)
 - `--verbose`: Enable verbose logging (default: false)
 - `--debug`: Enable debug logging (default: false)
+- `--overrides`: Enable instruction overrides (allows custom instruction files to override defaults)
+- `--config-dir <configDir>`: Specify a custom configuration directory (default: '.kodrdriv')
+- `--excluded-paths [excludedPatterns...]`: Paths to exclude from the diff (can specify multiple patterns)
 - `--version`: Display version information
 
 ### Commit Command Options
@@ -71,6 +183,214 @@ KodrDriv provides several command line options to customize its behavior:
 - `--context <context>`: Provide additional context (as a string or file path) to guide the commit message generation. This context is included in the prompt sent to the AI and can be used to specify the purpose, theme, or any special considerations for the commit.
 - `--message-limit <messageLimit>`: Limit the number of recent commit messages (from git log) to include in the prompt for context (default: 10). This can help focus the AI on the most relevant recent changes.
 
+### Publish Command Options
+
+- `--merge-method <method>`: Method to merge pull requests during the publish process (default: 'squash')
+  - Available methods: 'merge', 'squash', 'rebase'
+  - `merge`: Creates a merge commit that combines the feature branch into the target branch
+  - `squash`: Combines all commits from the feature branch into a single commit on the target branch
+  - `rebase`: Replays commits from the feature branch onto the target branch without creating a merge commit
+
+#### Dependency Update Configuration
+
+The publish command supports selective dependency updates through the `dependencyUpdatePatterns` configuration option. This allows you to specify which dependencies should be updated during the release process instead of updating all dependencies.
+
+**Configuration:**
+```json
+{
+  "publish": {
+    "dependencyUpdatePatterns": ["@company/*", "@myorg/*", "specific-package"]
+  }
+}
+```
+
+**Behavior:**
+- When patterns are specified, only dependencies matching those patterns will be updated
+- Patterns can include npm scopes (e.g., `@company/*`) or specific package names
+- If no patterns are configured, all dependencies are updated (default behavior)
+- This is particularly useful when developing a set of related packages where you want to ensure you're using the latest versions of your organization's packages while keeping other dependencies stable
+
+#### Environment Variable Configuration
+
+The publish command includes comprehensive environment variable validation to ensure all required credentials and tokens are available before starting the release process. This prevents failures partway through the publication workflow.
+
+**Core Required Environment Variables:**
+
+The following environment variables are required by default for all publish operations:
+
+- `GITHUB_TOKEN`: Required for GitHub API operations (creating pull requests, releases, etc.)
+- `OPENAI_API_KEY`: Required for AI-powered commit message and release note generation
+
+**Configurable Additional Environment Variables:**
+
+You can specify additional required environment variables specific to your project or organization:
+
+**Configuration (config.yaml):**
+```yaml
+publish:
+  requiredEnvVars:
+    - NODE_AUTH_TOKEN        # Often needed for publishing to npm
+    - DEPLOY_KEY            # Custom deployment credentials
+    - CUSTOM_API_TOKEN      # Organization-specific tokens
+    - CODECOV_TOKEN         # Code coverage reporting
+```
+
+**Configuration (config.json):**
+```json
+{
+  "publish": {
+    "requiredEnvVars": [
+      "NODE_AUTH_TOKEN",
+      "DEPLOY_KEY", 
+      "CUSTOM_API_TOKEN",
+      "CODECOV_TOKEN"
+    ]
+  }
+}
+```
+
+**Automatic .npmrc Scanning:**
+
+The publish command automatically scans your `.npmrc` file for environment variable references and includes them in the validation. It detects common patterns like:
+
+- `${NODE_AUTH_TOKEN}` - Curly brace syntax
+- `$NODE_AUTH_TOKEN` - Direct variable reference
+
+Example `.npmrc` file:
+```
+@myorg:registry=https://npm.pkg.github.com/
+//npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}
+```
+
+In this case, `NODE_AUTH_TOKEN` would be automatically detected and validated.
+
+**Validation Behavior:**
+- All environment variable checks happen during the initial prechecks phase
+- If any required environment variables are missing, the publish command fails immediately with a clear error message
+- The error message lists all missing variables at once, making it easy to set them all before retrying
+- Variables from configuration, .npmrc scanning, and core requirements are combined and deduplicated
+
+**Example Error:**
+```
+Missing required environment variables: NODE_AUTH_TOKEN, DEPLOY_KEY. 
+Please set these environment variables before running publish.
+```
+
+**Security Best Practices:**
+- Store sensitive environment variables in your CI/CD system's secure variable storage
+- Use tools like 1Password CLI, HashiCorp Vault, or similar for local development
+- Never commit environment variables or tokens to your repository
+- Consider using `.env` files (with proper .gitignore configuration) for local development
+
+#### Workspace Package Management
+
+The publish command provides options to control whether workspace packages should be linked or unlinked during the release process. Both operations are enabled by default for backward compatibility, but can be disabled if needed.
+
+**Configuration Options:**
+
+- `linkWorkspacePackages` (boolean, default: true): Controls whether to restore linked workspace packages after the publish process completes
+- `unlinkWorkspacePackages` (boolean, default: true): Controls whether to unlink workspace packages before starting the publish process
+
+**Configuration Example:**
+```json
+{
+  "publish": {
+    "linkWorkspacePackages": false,
+    "unlinkWorkspacePackages": false,
+    "mergeMethod": "squash"
+  }
+}
+```
+
+**Use Cases:**
+
+- **Skip Unlinking**: Set `unlinkWorkspacePackages: false` if you want to publish using your current workspace configuration without switching to registry dependencies
+- **Skip Linking**: Set `linkWorkspacePackages: false` if you want to leave the project in a "release-ready" state after publishing, with registry dependencies instead of workspace links
+- **Skip Both**: Disable both options if you're managing workspace configuration manually or using a different dependency management strategy
+
+**Default Behavior:**
+When both options are enabled (default), the publish command will:
+1. Unlink workspace packages before starting (switching to registry dependencies)
+2. Perform the release process with registry dependencies
+3. Restore workspace links after completion (returning to local development mode)
+
+This ensures that releases are published with proper registry dependencies while maintaining local development convenience.
+
+#### prepublishOnly Script Requirement
+
+The publish command requires a `prepublishOnly` script to be defined in your `package.json`. This script should contain all the checks and builds necessary to verify your project is ready for release.
+
+**Example package.json:**
+```json
+{
+  "scripts": {
+    "prepublishOnly": "pnpm run clean && pnpm run lint && pnpm run build && pnpm run test",
+    "clean": "rimraf dist",
+    "lint": "eslint src/",
+    "build": "tsc",
+    "test": "vitest run"
+  }
+}
+```
+
+**Why prepublishOnly?**
+- The `prepublishOnly` script is an npm/pnpm standard that runs automatically before publishing packages
+- It ensures consistent pre-flight checks regardless of how the package is published
+- It allows projects to define their own specific validation pipeline
+- The publish command validates this script exists during the initial prechecks phase
+
+**Common prepublishOnly Patterns:**
+- `"prepublishOnly": "npm run test"` - Run tests only
+- `"prepublishOnly": "npm run build && npm run test"` - Build and test
+- `"prepublishOnly": "npm run lint && npm run build && npm run test"` - Full validation pipeline
+- `"prepublishOnly": "npm run ci"` - Delegate to a CI script that includes all checks
+
+If this script is missing, the publish command will fail immediately with a helpful error message explaining the requirement.
+
+### Link Command Options
+
+- `--scope-roots <scopeRoots>`: JSON mapping of scopes to root directories for package discovery
+  - **Format**: `'{"@scope": "path", "@another": "path"}'`
+  - **Example**: `'{"@company": "../", "@myorg": "../../packages/"}'`
+  - **Required**: At least one scope mapping must be provided
+- `--workspace-file <workspaceFile>`: Path to the workspace file to create/update (default: 'pnpm-workspace.yaml')
+  - Can specify custom workspace file names or paths
+  - Useful if your project uses non-standard workspace file naming
+
+#### Scope Root Configuration
+
+The `--scope-roots` option accepts a JSON object mapping package scopes to their corresponding root directories. Each entry tells the link command where to look for packages with that scope.
+
+**Configuration Examples:**
+
+```bash
+# Single scope
+kodrdriv link --scope-roots '{"@company": "../"}'
+
+# Multiple scopes with different paths
+kodrdriv link --scope-roots '{"@company": "../", "@tools": "../../tools/", "@shared": "../shared-packages/"}'
+
+# Absolute paths (not recommended for portability)
+kodrdriv link --scope-roots '{"@company": "/Users/dev/projects/company-packages/"}'
+```
+
+**Path Resolution:**
+- Relative paths are resolved from the current working directory
+- Use `../` to scan the parent directory
+- Use `../../` to scan two levels up
+- Multiple levels and subdirectories are supported: `../../company/packages/`
+
+**Package Discovery Process:**
+1. For each scope root, the command lists all subdirectories
+2. It reads each subdirectory's `package.json` to get the actual package name
+3. It matches discovered package names against your project's dependencies
+4. Matching packages are added to the workspace configuration
+
+This approach handles complex scenarios where:
+- Directory names don't match package names (e.g., `logging-lib` directory contains `@company/logging`)
+- Packages are organized in different directory structures
+- Multiple related packages exist in the same scope root
+
 ### OpenAI Configuration
 
 - `--openai-api-key <key>`: OpenAI API key (can also be set via OPENAI_API_KEY environment variable)
@@ -131,6 +451,54 @@ kodrdriv commit --context "Refactoring for performance" --message-limit 5
 kodrdriv release --context "Quarterly release, focus on stability" --message-limit 20
 ```
 
+Publish with different merge methods:
+```bash
+# Use default squash merge
+kodrdriv publish
+
+# Use merge commit (preserves individual commits)
+kodrdriv publish --merge-method merge
+
+# Use rebase (clean linear history)
+kodrdriv publish --merge-method rebase
+```
+
+Use excluded paths to filter diff content:
+```bash
+# Exclude specific files or directories from diff analysis
+kodrdriv commit --excluded-paths "*.lock" "dist/" "node_modules/"
+
+# Exclude patterns from release notes
+kodrdriv release --excluded-paths "package-lock.json" "pnpm-lock.yaml"
+```
+
+Use overrides with custom instructions:
+```bash
+# Enable instruction overrides (requires custom instruction files in .kodrdriv/instructions/)
+kodrdriv commit --overrides
+
+# Use custom config directory with overrides
+kodrdriv release --config-dir ~/my-kodrdriv-config --overrides
+```
+
+Link local packages for development:
+```bash
+# Basic linking with single scope
+kodrdriv link --scope-roots '{"@company": "../"}'
+
+# Multiple scopes with different root directories
+kodrdriv link --scope-roots '{"@company": "../", "@tools": "../../tools/"}'
+
+# Dry run to preview changes
+kodrdriv link --scope-roots '{"@company": "../"}' --dry-run --verbose
+
+# Custom workspace file
+kodrdriv link --scope-roots '{"@company": "../"}' --workspace-file "workspace.yaml"
+
+# Real-world example: linking @company packages from company directory
+kodrdriv link --scope-roots '{"@company": "../../company/"}'
+```
+
 ### Configuration Directory
 
 KodrDriv uses a configuration directory to store custom settings, instructions, and other configuration files. You can specify a custom location using the `--config-dir` option:
@@ -152,9 +520,58 @@ The configuration directory structure is as follows:
 │   ├── release.md        # Override for release instructions
 │   ├── release-pre.md    # Content prepended to default release instructions
 │   └── release-post.md   # Content appended to default release instructions
+├── config.json           # Main configuration file
 └── ...                   # Other configuration files
 ```
 
+### Configuration File
+
+You can create a `config.json` file in your `.kodrdriv` directory to set default options for all commands. This allows you to avoid repeating command-line options and ensures consistent behavior across your project.
+
+Example configuration file (`.kodrdriv/config.json`):
+
+```json
+{
+  "model": "gpt-4o-mini",
+  "verbose": true,
+  "contextDirectories": ["src", "docs"],
+  "publish": {
+    "mergeMethod": "merge",
+    "dependencyUpdatePatterns": ["@company/*", "@myorg/*"],
+    "requiredEnvVars": ["NODE_AUTH_TOKEN", "CUSTOM_TOKEN"],
+    "linkWorkspacePackages": true,
+    "unlinkWorkspacePackages": true
+  },
+  "commit": {
+    "add": true,
+    "messageLimit": 5
+  },
+  "release": {
+    "from": "main",
+    "to": "HEAD",
+    "messageLimit": 10
+  },
+  "link": {
+    "scopeRoots": {
+      "@company": "../",
+      "@myorg": "../../org-packages/",
+      "@tools": "../shared-tools/"
+    },
+    "workspaceFile": "pnpm-workspace.yaml"
+  },
+  "excludedPatterns": [
+    "node_modules",
+    "dist",
+    "*.log"
+  ]
+}
+```
+
+Configuration options set in the file can be overridden by command-line arguments. The precedence order is:
+1. Command-line arguments (highest priority)
+2. Configuration file
+3. Default values (lowest priority)
+
 ## Default Instructions
 
 KodrDriv comes with default instructions that guide the AI in generating release notes or change logs. These instructions are defined in the source code:
@@ -338,10 +755,10 @@ Whether you're merging branches or writing books, kodrdriv is built for that end
 
 ### Release Command Options
 
-- `--from <from>`: Branch or reference to generate release notes from
-- `--to <to>`: Branch or reference to generate release notes to
+- `--from <from>`: Branch or reference to generate release notes from (default: 'main')
+- `--to <to>`: Branch or reference to generate release notes to (default: 'HEAD')
 - `--context <context>`: Provide additional context (as a string or file path) to guide the release notes generation. This context is included in the prompt sent to the AI and can be used to specify the purpose, theme, or any special considerations for the release.
-- `--message-limit <messageLimit>`: Limit the number of recent commit messages (from git log) to include in the release notes prompt (default: 10).
+- `--message-limit <messageLimit>`: Limit the number of recent commit messages (from git log) to include in the release notes prompt (default: 10). Reducing this number can make the summary more focused, while increasing it provides broader historical context.
 
 ### Explanation