@releasekit/version 0.3.0-next.4 → 0.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -22,6 +22,8 @@ npm install -g @releasekit/version
22
22
  pnpm add -g @releasekit/version
23
23
  ```
24
24
 
25
+ > **Note:** This package is ESM only and requires Node.js 20+.
26
+
25
27
  ## Quick Start
26
28
 
27
29
  ```bash
@@ -82,7 +84,7 @@ When using `--json`, the tool outputs structured data including version bumps an
82
84
  ]
83
85
  }
84
86
  ],
85
- "commitMessage": "chore(release): v1.2.3",
87
+ "commitMessage": "chore: release v1.2.3",
86
88
  "tags": ["v1.2.3"]
87
89
  }
88
90
  ```
@@ -99,7 +101,7 @@ Configure via `releasekit.config.json`:
99
101
  "preset": "conventionalcommits",
100
102
  "versionPrefix": "v",
101
103
  "tagTemplate": "${prefix}${version}",
102
- "commitMessage": "chore(release): v${version}",
104
+ "commitMessage": "chore: release ${packageName} v${version}",
103
105
  "sync": true,
104
106
  "packages": ["@mycompany/*"],
105
107
  "skip": ["docs", "e2e"],
@@ -121,7 +123,7 @@ Configure via `releasekit.config.json`:
121
123
  | `preset` | Conventional commits preset | `"conventionalcommits"` |
122
124
  | `versionPrefix` | Tag version prefix | `"v"` |
123
125
  | `tagTemplate` | Git tag template | `"${prefix}${version}"` |
124
- | `commitMessage` | Commit message template | `"chore(release): ${version}"` |
126
+ | `commitMessage` | Commit message template | `"chore: release ${packageName} v${version}"` |
125
127
  | `sync` | Version all packages together | `false` |
126
128
  | `packages` | Package name patterns to include | all |
127
129
  | `skip` | Package name patterns to exclude | `[]` |
package/dist/cli.js CHANGED
@@ -1,106 +1 @@
1
1
  #!/usr/bin/env node
2
- import {
3
- VersionEngine,
4
- enableJsonOutput,
5
- loadConfig,
6
- log,
7
- printJsonOutput
8
- } from "./chunk-ZEXPJ53Z.js";
9
- import "./chunk-GQLJ7JQY.js";
10
- import "./chunk-LMPZV35Z.js";
11
-
12
- // src/cli.ts
13
- import * as fs from "fs";
14
- import path from "path";
15
- import { Command } from "commander";
16
- function getPackageVersion() {
17
- try {
18
- const packageJsonPath = path.resolve(path.dirname(import.meta.url.replace("file:", "")), "../package.json");
19
- const packageJsonContent = fs.readFileSync(packageJsonPath, "utf-8");
20
- const packageJson = JSON.parse(packageJsonContent);
21
- return packageJson.version || "0.0.0";
22
- } catch (error) {
23
- console.error("Failed to read package version:", error);
24
- return "0.0.0";
25
- }
26
- }
27
- async function main() {
28
- const program = new Command();
29
- program.name("releasekit-version").description("Version a package or packages based on conventional commits").version(getPackageVersion()).command("version", { isDefault: true }).description("Version a package or packages based on configuration").option("-c, --config <path>", "Path to config file (defaults to releasekit.config.json in current directory)").option("-d, --dry-run", "Dry run (no changes made)", false).option("-b, --bump <type>", "Specify bump type (patch|minor|major)").option("-p, --prerelease [identifier]", "Create prerelease version").option("-s, --sync", "Use synchronized versioning across all packages").option("-j, --json", "Output results as JSON", false).option("-t, --target <packages>", "Comma-delimited list of package names to target").option("--project-dir <path>", "Project directory to run commands in", process.cwd()).action(async (options) => {
30
- if (options.json) {
31
- enableJsonOutput(options.dryRun);
32
- }
33
- try {
34
- const originalCwd = process.cwd();
35
- if (options.projectDir && options.projectDir !== originalCwd) {
36
- try {
37
- process.chdir(options.projectDir);
38
- log(`Changed working directory to: ${options.projectDir}`, "debug");
39
- } catch (error) {
40
- throw new Error(
41
- `Failed to change to directory "${options.projectDir}": ${error instanceof Error ? error.message : String(error)}`
42
- );
43
- }
44
- }
45
- const config = loadConfig({ cwd: options.projectDir, configPath: options.config });
46
- log(`Loaded configuration from ${options.config || "releasekit.config.json"}`, "info");
47
- if (options.dryRun) config.dryRun = true;
48
- if (options.sync) config.sync = true;
49
- if (options.bump) config.type = options.bump;
50
- if (options.prerelease) {
51
- config.prereleaseIdentifier = options.prerelease === true ? "next" : options.prerelease;
52
- config.isPrerelease = true;
53
- }
54
- const cliTargets = options.target ? options.target.split(",").map((t) => t.trim()) : [];
55
- if (cliTargets.length > 0) {
56
- config.packages = cliTargets;
57
- log(`CLI targets specified: ${cliTargets.join(", ")}`, "info");
58
- }
59
- const engine = new VersionEngine(config, !!options.json);
60
- const pkgsResult = await engine.getWorkspacePackages();
61
- const resolvedCount = pkgsResult.packages.length;
62
- log(`Resolved ${resolvedCount} packages from workspace`, "debug");
63
- log(`Config packages: ${JSON.stringify(config.packages)}`, "debug");
64
- log(`Config sync: ${config.sync}`, "debug");
65
- if (config.sync) {
66
- log("Using sync versioning strategy.", "info");
67
- engine.setStrategy("sync");
68
- await engine.run(pkgsResult);
69
- } else if (resolvedCount === 1) {
70
- log("Using single package versioning strategy.", "info");
71
- if (cliTargets.length > 0) {
72
- log("--target flag is ignored for single package strategy.", "warning");
73
- }
74
- engine.setStrategy("single");
75
- await engine.run(pkgsResult);
76
- } else if (resolvedCount === 0) {
77
- throw new Error("No packages found in workspace");
78
- } else {
79
- log("Using async versioning strategy.", "info");
80
- if (cliTargets.length > 0) {
81
- log(`Targeting specific packages: ${cliTargets.join(", ")}`, "info");
82
- }
83
- engine.setStrategy("async");
84
- await engine.run(pkgsResult, cliTargets);
85
- }
86
- log("Versioning process completed.", "success");
87
- printJsonOutput();
88
- } catch (error) {
89
- const { BaseVersionError } = await import("./baseError-ZCZHF6A2.js");
90
- if (BaseVersionError.isVersionError(error)) {
91
- error.logError();
92
- } else {
93
- log(`Error: ${error instanceof Error ? error.message : String(error)}`, "error");
94
- }
95
- process.exit(1);
96
- }
97
- });
98
- program.parse();
99
- }
100
- async function run() {
101
- await main();
102
- }
103
- main();
104
- export {
105
- run
106
- };
@@ -1,17 +1,17 @@
1
1
  # CI/CD Integration
2
2
 
3
- `package-versioner` is designed to work seamlessly in CI/CD pipelines, making it easy to automate versioning as part of your release workflow.
3
+ `releasekit-version` is designed to work seamlessly in CI/CD pipelines, making it easy to automate versioning as part of your release workflow.
4
4
 
5
5
  ## JSON Output Mode
6
6
 
7
- For programmatic consumption in CI/CD scripts, `package-versioner` provides a structured JSON output option:
7
+ For programmatic consumption in CI/CD scripts, `releasekit-version` provides a structured JSON output option:
8
8
 
9
9
  ```bash
10
10
  # Output results in JSON format
11
- npx package-versioner --json
11
+ npx releasekit-version --json
12
12
 
13
13
  # Combine with dry-run for planning
14
- npx package-versioner --dry-run --json
14
+ npx releasekit-version --dry-run --json
15
15
  ```
16
16
 
17
17
  This will suppress all normal console output and instead output a single JSON object containing:
@@ -39,7 +39,7 @@ This will suppress all normal console output and instead output a single JSON ob
39
39
  ]
40
40
  }
41
41
  ],
42
- "commitMessage": "chore(release): v1.2.3", // The commit message that was used
42
+ "commitMessage": "chore: release my-package v1.2.3", // The commit message that was used
43
43
  "tags": [ // Array of tags that were created
44
44
  "v1.2.3" // or package-specific tags in targeted mode
45
45
  ]
@@ -58,7 +58,7 @@ The structured JSON output provides several advantages for CI/CD integration:
58
58
 
59
59
  ## Sample CI/CD Integration Patterns
60
60
 
61
- Here are some common ways to incorporate `package-versioner` into your CI/CD pipeline:
61
+ Here are some common ways to incorporate `releasekit-version` into your CI/CD pipeline:
62
62
 
63
63
  ### GitHub Actions Workflow Example
64
64
 
@@ -77,12 +77,12 @@ jobs:
77
77
  new_version: ${{ steps.version.outputs.new_version }}
78
78
 
79
79
  steps:
80
- - uses: actions/checkout@v3
80
+ - uses: actions/checkout@v6
81
81
  with:
82
82
  fetch-depth: 0 # Important for git history
83
83
 
84
84
  - name: Setup Node.js
85
- uses: actions/setup-node@v3
85
+ uses: actions/setup-node@v6
86
86
  with:
87
87
  node-version: '18'
88
88
 
@@ -93,7 +93,7 @@ jobs:
93
93
  id: version
94
94
  run: |
95
95
  # Run in JSON mode for parsing
96
- VERSION_OUTPUT=$(npx package-versioner --json)
96
+ VERSION_OUTPUT=$(npx releasekit-version --json)
97
97
  echo "Version output: $VERSION_OUTPUT"
98
98
 
99
99
  # Use jq to parse the JSON output
@@ -127,7 +127,7 @@ determine_version:
127
127
  script:
128
128
  - npm ci
129
129
  - |
130
- VERSION_OUTPUT=$(npx package-versioner --json)
130
+ VERSION_OUTPUT=$(npx releasekit-version --json)
131
131
  echo "VERSION_OUTPUT=$VERSION_OUTPUT" >> version.env
132
132
 
133
133
  # Parse values for use in later stages
@@ -153,7 +153,7 @@ publish:
153
153
 
154
154
  ## Working with Tags in CI
155
155
 
156
- When using the targeted mode with `-t` flag, `package-versioner` creates package-specific tags (e.g., `@scope/package-a@1.2.0`) but not a global tag. If your release process needs a global tag, you can add a step to your CI/CD pipeline:
156
+ When using the targeted mode with `-t` flag, `releasekit-version` creates package-specific tags (e.g., `@scope/package-a@1.2.0`) but not a global tag. If your release process needs a global tag, you can add a step to your CI/CD pipeline:
157
157
 
158
158
  ```bash
159
159
  # Create a global tag based on the representative version
@@ -164,7 +164,7 @@ git push origin "v$NEW_VERSION"
164
164
 
165
165
  ## Environment Variables
166
166
 
167
- `package-versioner` respects the following environment variables:
167
+ `releasekit-version` respects the following environment variables:
168
168
 
169
169
  - `NO_COLOR=1`: Disables colored output in logs (automatically detected in CI environments)
170
170
  - `CI=true`: Most CI environments set this automatically, which helps the tool adjust its output behaviour
@@ -175,7 +175,7 @@ If you want to prevent additional CI runs when version commits are made, you can
175
175
 
176
176
  ```json
177
177
  {
178
- "commitMessage": "chore(release): ${version} [skip ci]",
178
+ "commitMessage": "chore: release ${packageName} v${version} [skip ci]",
179
179
  // other configuration options...
180
180
  }
181
181
  ```
@@ -1,6 +1,6 @@
1
1
  # Versioning Strategies and Concepts
2
2
 
3
- `package-versioner` offers flexible ways to determine the next version for your project based on its history and your configuration.
3
+ `releasekit-version` offers flexible ways to determine the next version for your project based on its history and your configuration.
4
4
 
5
5
  ## How the Next Version is Calculated
6
6
 
@@ -8,7 +8,7 @@ There are two primary methods the tool uses to decide the version bump (e.g., pa
8
8
 
9
9
  ### 1. Conventional Commits (`versionStrategy: "conventional"`)
10
10
 
11
- This is the default strategy. `package-versioner` analyzes Git commit messages since the last Git tag that follows semver patterns. It uses the [conventional-commits](https://www.conventionalcommits.org/) specification to determine the bump:
11
+ This is the default strategy. `releasekit-version` analyzes Git commit messages since the last Git tag that follows semver patterns. It uses the [conventional-commits](https://www.conventionalcommits.org/) specification to determine the bump:
12
12
 
13
13
  - **Patch Bump (e.g., 1.2.3 -> 1.2.4):** Triggered by `fix:` commit types.
14
14
  - **Minor Bump (e.g., 1.2.3 -> 1.3.0):** Triggered by `feat:` commit types.
@@ -67,7 +67,7 @@ This allows you to enforce version bumps based on your branching workflow (e.g.,
67
67
 
68
68
  ## Package Type Support
69
69
 
70
- `package-versioner` supports both JavaScript/TypeScript projects using `package.json` and Rust projects using `Cargo.toml`:
70
+ `releasekit-version` supports both JavaScript/TypeScript projects using `package.json` and Rust projects using `Cargo.toml`:
71
71
 
72
72
  ### JavaScript/TypeScript Projects
73
73
 
@@ -79,7 +79,7 @@ For Rust projects, the tool looks for and updates the `package.version` field in
79
79
 
80
80
  ### Mixed Projects with Both Manifests
81
81
 
82
- When both `package.json` and `Cargo.toml` exist in the same directory, `package-versioner` will:
82
+ When both `package.json` and `Cargo.toml` exist in the same directory, `releasekit-version` will:
83
83
 
84
84
  1. Update both manifest files independently with the same calculated version
85
85
  2. First check `package.json` for the current version (when no tags exist)
@@ -89,7 +89,7 @@ This allows you to maintain consistent versioning across JavaScript and Rust com
89
89
 
90
90
  ## Version Source Selection
91
91
 
92
- `package-versioner` uses a smart version source selection strategy to determine the base version for calculating the next version:
92
+ `releasekit-version` uses a smart version source selection strategy to determine the base version for calculating the next version:
93
93
 
94
94
  1. First, it checks for Git tags:
95
95
  - In normal mode: Uses the latest reachable tag, falling back to unreachable tags if needed
@@ -273,7 +273,7 @@ This configuration will process all packages in the `@mycompany` scope except fo
273
273
 
274
274
  ## Tag Templates and Configuration
275
275
 
276
- `package-versioner` provides flexible configuration for how Git tags are formatted, allowing you to customize the tag structure for both single package repositories and monorepos.
276
+ `releasekit-version` provides flexible configuration for how Git tags are formatted, allowing you to customize the tag structure for both single package repositories and monorepos.
277
277
 
278
278
  ### Tag Template Configuration
279
279
 
@@ -355,7 +355,7 @@ This would produce package tags like `@scope/package-name-v1.2.3` instead of `@s
355
355
 
356
356
  ## Troubleshooting Template Configuration
357
357
 
358
- `package-versioner` provides helpful warnings when template configurations don't match your project setup. Here are common issues and their solutions:
358
+ `releasekit-version` provides helpful warnings when template configurations don't match your project setup. Here are common issues and their solutions:
359
359
 
360
360
  ### Template Contains ${packageName} but No Package Name Available
361
361
 
@@ -430,7 +430,7 @@ For global commit messages, use templates without `${packageName}`:
430
430
 
431
431
  ## Monorepo Versioning Modes
432
432
 
433
- While primarily used for single packages now, `package-versioner` retains options for monorepo workflows, controlled mainly by the `sync` flag in `version.config.json`.
433
+ While primarily used for single packages now, `releasekit-version` retains options for monorepo workflows, controlled mainly by the `sync` flag in `version.config.json`.
434
434
 
435
435
  ### Sync Mode (`sync: true`)
436
436
 
@@ -457,13 +457,13 @@ This is the default if the `sync` flag is present and true.
457
457
  - It calculates an appropriate version bump **independently for each targeted package** based on its commit history.
458
458
  - The `package.json` file of each successfully updated targeted package is modified.
459
459
  - An **individual Git tag** (e.g., `packageName@1.2.3`) is created **for each successfully updated package** immediately after its version is bumped.
460
- - Finally, a **single commit** is created including all the updated `package.json` files, using a summary commit message (e.g., `chore(release): pkg-a, pkg-b 1.2.3 [skip-ci]`).
461
- - **Important:** Only package-specific tags are created. The global tag (e.g., `v1.2.3`) is **not** automatically generated in this mode. If your release process (like GitHub Releases) depends on a global tag, you'll need to create it manually in your CI/CD script *after* `package-versioner` completes.
460
+ - Finally, a **single commit** is created including all the updated `package.json` files, using a summary commit message (e.g., `chore: release pkg-a, pkg-b v1.2.3 [skip ci]`).
461
+ - **Important:** Only package-specific tags are created. The global tag (e.g., `v1.2.3`) is **not** automatically generated in this mode. If your release process (like GitHub Releases) depends on a global tag, you'll need to create it manually in your CI/CD script *after* `releasekit-version` completes.
462
462
  - **Use Case:** Releasing specific packages independently while still tagging each released package individually.
463
463
 
464
464
  ## Prerelease Handling
465
465
 
466
- `package-versioner` provides flexible handling for prerelease versions, allowing both creation of prereleases and promotion to stable releases.
466
+ `releasekit-version` provides flexible handling for prerelease versions, allowing both creation of prereleases and promotion to stable releases.
467
467
 
468
468
  ### Creating Prereleases
469
469
 
@@ -471,7 +471,7 @@ Use the `--prerelease` flag with an identifier to create a prerelease version:
471
471
 
472
472
  ```bash
473
473
  # Create a beta prerelease
474
- npx package-versioner --bump minor --prerelease beta
474
+ npx releasekit-version --bump minor --prerelease beta
475
475
  # Result: 1.0.0 -> 1.1.0-beta.0
476
476
  ```
477
477
 
@@ -485,11 +485,11 @@ You can also set a default prerelease identifier in your `version.config.json`:
485
485
 
486
486
  ### Promoting Prereleases to Stable Releases
487
487
 
488
- When using standard bump types (`major`, `minor`, `patch`) with the `--bump` flag on a prerelease version, `package-versioner` will automatically clean the prerelease identifier:
488
+ When using standard bump types (`major`, `minor`, `patch`) with the `--bump` flag on a prerelease version, `releasekit-version` will automatically clean the prerelease identifier:
489
489
 
490
490
  ```bash
491
491
  # Starting from version 1.0.0-beta.1
492
- npx package-versioner --bump major
492
+ npx releasekit-version --bump major
493
493
  # Result: 1.0.0-beta.1 -> 2.0.0 (not 2.0.0-beta.0)
494
494
  ```
495
495
 
package/package.json CHANGED
@@ -1,9 +1,8 @@
1
1
  {
2
2
  "name": "@releasekit/version",
3
- "version": "0.3.0-next.4",
3
+ "version": "0.3.0",
4
4
  "description": "Semantic versioning based on Git history and conventional commits",
5
5
  "type": "module",
6
- "main": "./dist/index.cjs",
7
6
  "module": "./dist/index.js",
8
7
  "types": "./dist/index.d.ts",
9
8
  "exports": {
@@ -11,10 +10,12 @@
11
10
  "import": {
12
11
  "types": "./dist/index.d.ts",
13
12
  "default": "./dist/index.js"
14
- },
15
- "require": {
16
- "types": "./dist/index.d.cts",
17
- "default": "./dist/index.cjs"
13
+ }
14
+ },
15
+ "./cli": {
16
+ "import": {
17
+ "types": "./dist/cli.d.ts",
18
+ "default": "./dist/cli.js"
18
19
  }
19
20
  }
20
21
  },
@@ -59,9 +60,8 @@
59
60
  "git-semver-tags": "^8.0.1",
60
61
  "micromatch": "^4.0.8",
61
62
  "semver": "^7.7.4",
62
- "smol-toml": "^1.6.0",
63
- "@releasekit/config": "0.1.0",
64
- "@releasekit/core": "0.1.0"
63
+ "smol-toml": "^1.6.1",
64
+ "zod": "^4.3.6"
65
65
  },
66
66
  "devDependencies": {
67
67
  "@biomejs/biome": "^2.4.6",
@@ -71,14 +71,16 @@
71
71
  "@vitest/coverage-v8": "^4.1.0",
72
72
  "tsup": "^8.5.1",
73
73
  "typescript": "^5.9.3",
74
- "vitest": "^4.1.0"
74
+ "vitest": "^4.1.0",
75
+ "@releasekit/core": "0.0.0",
76
+ "@releasekit/config": "0.0.0"
75
77
  },
76
78
  "engines": {
77
79
  "node": ">=20"
78
80
  },
79
81
  "scripts": {
80
- "build": "tsup src/index.ts src/cli.ts --format esm,cjs --dts",
81
- "dev": "tsup src/index.ts src/cli.ts --format esm,cjs --watch --dts",
82
+ "build": "tsup",
83
+ "dev": "tsup --watch",
82
84
  "clean": "rm -rf dist coverage .turbo",
83
85
  "test": "vitest run --dir test/unit",
84
86
  "test:unit": "vitest run --coverage --dir test/unit",
@@ -93,7 +93,7 @@
93
93
  "commitMessage": {
94
94
  "type": "string",
95
95
  "minLength": 1,
96
- "default": "chore(release): v${version}",
96
+ "default": "chore: release ${packageName} v${version}",
97
97
  "description": "Template for commit messages. Available variables: ${version}, ${packageName}, ${scope}"
98
98
  },
99
99
  "prereleaseIdentifier": {
@@ -1,7 +0,0 @@
1
- import {
2
- BaseVersionError
3
- } from "./chunk-GQLJ7JQY.js";
4
- export {
5
- BaseVersionError as BasePackageVersionerError,
6
- BaseVersionError
7
- };
@@ -1,18 +0,0 @@
1
- // src/errors/baseError.ts
2
- import { ReleaseKitError } from "@releasekit/core";
3
- var BaseVersionError = class _BaseVersionError extends ReleaseKitError {
4
- code;
5
- suggestions;
6
- constructor(message, code, suggestions) {
7
- super(message);
8
- this.code = code;
9
- this.suggestions = suggestions ?? [];
10
- }
11
- static isVersionError(error) {
12
- return error instanceof _BaseVersionError;
13
- }
14
- };
15
-
16
- export {
17
- BaseVersionError
18
- };
@@ -1,20 +0,0 @@
1
- // src/git/commandExecutor.ts
2
- import { execFile, execFileSync } from "child_process";
3
- var execAsync = (file, args, options) => {
4
- const defaultOptions = { maxBuffer: 1024 * 1024 * 10, ...options };
5
- return new Promise((resolve, reject) => {
6
- execFile(file, args, defaultOptions, (error, stdout, stderr) => {
7
- if (error) {
8
- reject(error);
9
- } else {
10
- resolve({ stdout: stdout.toString(), stderr: stderr.toString() });
11
- }
12
- });
13
- });
14
- };
15
- var execSync = (file, args, options) => execFileSync(file, args, { maxBuffer: 1024 * 1024 * 10, ...options });
16
-
17
- export {
18
- execAsync,
19
- execSync
20
- };