chore: release v0.10.3#719
Conversation
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings. WalkthroughThis PR performs a version release bump from v0.10.2 to v0.10.3 across the entire monorepo, updating version fields in the root and all workspace package.json files, adding a new CHANGELOG entry dated 2025-11-20 with two chore items, and updating the CLI version constant. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks✅ Passed checks (5 passed)
Tip 📝 Customizable high-level summaries are now available in beta!You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.
Example instruction:
Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (17)
CHANGELOG.md(1 hunks)examples/access-protection/package.json(1 hunks)examples/cors/package.json(1 hunks)examples/data-transportation/package.json(1 hunks)examples/error-handling/package.json(1 hunks)examples/health-checks/package.json(1 hunks)examples/hello-world/package.json(1 hunks)examples/load-balancing/package.json(1 hunks)examples/middleware/package.json(1 hunks)examples/multi-version/package.json(1 hunks)examples/resources/package.json(1 hunks)examples/segmentation/package.json(1 hunks)package.json(1 hunks)packages/cli/src/commands/ShowVersion.ts(1 hunks)packages/create-jitar/package.json(1 hunks)packages/jitar/package.json(1 hunks)packages/plugin-vite/package.json(1 hunks)
🧰 Additional context used
🧠 Learnings (4)
📚 Learning: 2025-07-28T19:38:55.816Z
Learnt from: basmasking
Repo: MaskingTechnology/jitar PR: 678
File: packages/init/templates/jitar-only/package.json:6-6
Timestamp: 2025-07-28T19:38:55.816Z
Learning: In jitar templates (like packages/init/templates/jitar-only/package.json), the jitar build command doesn't produce a .jitar folder. Templates use a jitar.json configuration where both source and target point to "./dist", unlike examples where a .jitar folder may be generated.
Applied to files:
examples/middleware/package.jsonpackage.jsonexamples/error-handling/package.jsonpackages/jitar/package.jsonexamples/data-transportation/package.jsonexamples/health-checks/package.jsonexamples/hello-world/package.jsonexamples/cors/package.jsonexamples/resources/package.jsonexamples/multi-version/package.jsonpackages/create-jitar/package.jsonexamples/access-protection/package.jsonexamples/load-balancing/package.jsonexamples/segmentation/package.json
📚 Learning: 2025-07-28T19:38:55.816Z
Learnt from: basmasking
Repo: MaskingTechnology/jitar PR: 678
File: packages/init/templates/jitar-only/package.json:6-6
Timestamp: 2025-07-28T19:38:55.816Z
Learning: Jitar templates use a jitar.json configuration structure with "source": "./dist", "target": "./dist", and "segments": "./segments", where the CLI rewrites files from the dist folder back to the dist folder, and segment configuration files are found in the segments folder.
Applied to files:
examples/middleware/package.jsonpackage.jsonexamples/error-handling/package.jsonpackages/jitar/package.jsonexamples/data-transportation/package.jsonexamples/health-checks/package.jsonexamples/hello-world/package.jsonexamples/cors/package.jsonexamples/resources/package.jsonexamples/multi-version/package.jsonpackages/create-jitar/package.jsonexamples/access-protection/package.jsonexamples/load-balancing/package.jsonexamples/segmentation/package.json
📚 Learning: 2025-07-28T19:44:53.054Z
Learnt from: basmasking
Repo: MaskingTechnology/jitar PR: 678
File: packages/validation/package.json:16-16
Timestamp: 2025-07-28T19:44:53.054Z
Learning: In the jitar monorepo, standardized tooling dependencies like rimraf, vitest, and typescript are intentionally defined once at the root level package.json and rely on npm hoisting rather than being duplicated in each individual package's package.json file. Package-specific dependencies should be in individual package.json files, but common tooling should be centralized.
Applied to files:
examples/middleware/package.jsonpackage.jsonexamples/error-handling/package.jsonexamples/data-transportation/package.jsonexamples/health-checks/package.jsonexamples/hello-world/package.jsonexamples/cors/package.jsonexamples/resources/package.jsonexamples/multi-version/package.jsonexamples/access-protection/package.jsonexamples/load-balancing/package.jsonexamples/segmentation/package.json
📚 Learning: 2025-11-01T12:49:12.253Z
Learnt from: basmasking
Repo: MaskingTechnology/jitar PR: 706
File: examples/resources/package.json:11-14
Timestamp: 2025-11-01T12:49:12.253Z
Learning: Examples in the jitar monorepo (files under examples/ directory) are not included in the workspace setup, so npm hoisting does not work for them. Unlike packages, examples must declare their own devDependencies (like rimraf, typescript, etc.) directly in their package.json files.
Applied to files:
examples/middleware/package.jsonpackage.jsonexamples/error-handling/package.jsonexamples/data-transportation/package.jsonexamples/health-checks/package.jsonexamples/hello-world/package.jsonexamples/cors/package.jsonexamples/resources/package.jsonexamples/multi-version/package.jsonexamples/access-protection/package.jsonexamples/load-balancing/package.jsonexamples/segmentation/package.json
🪛 markdownlint-cli2 (0.18.1)
CHANGELOG.md
1-1: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
4-4: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
🔇 Additional comments (15)
packages/jitar/package.json (1)
3-3: LGTM! Version bump is correct.The main package version has been correctly updated to 0.10.3, consistent with the release PR objectives.
examples/hello-world/package.json (1)
16-16: LGTM! Dependency version updated correctly.The jitar dependency has been correctly bumped to 0.10.3, matching the package release.
examples/error-handling/package.json (1)
19-19: LGTM! Dependency version updated correctly.The jitar dependency has been correctly bumped to 0.10.3.
examples/multi-version/package.json (1)
16-16: LGTM! Dependency version updated correctly.The jitar dependency has been correctly bumped to 0.10.3.
examples/load-balancing/package.json (1)
19-19: LGTM! Dependency version updated correctly.The jitar dependency has been correctly bumped to 0.10.3.
packages/create-jitar/package.json (1)
3-3: LGTM! Version bump is correct.The create-jitar package version has been correctly updated to 0.10.3.
examples/segmentation/package.json (1)
19-19: Verified: All jitar dependency versions correctly updated to 0.10.3All 11 example packages (access-protection, cors, data-transportation, error-handling, health-checks, hello-world, load-balancing, middleware, multi-version, resources, segmentation) have been consistently updated to jitar 0.10.3. No remaining 0.10.2 references found in package.json files or TypeScript source code.
examples/middleware/package.json (1)
16-16: Version bump is correct and consistent across the repository.The jitar dependency is properly updated to v0.10.3.
examples/resources/package.json (1)
16-16: Version bump is correct and consistent.The jitar dependency is properly updated to v0.10.3.
examples/data-transportation/package.json (1)
19-19: Version bump is correct and consistent.The jitar dependency is properly updated to v0.10.3.
examples/access-protection/package.json (1)
19-19: Version bump is correct and consistent.The jitar dependency is properly updated to v0.10.3.
package.json (1)
3-3: Root version correctly bumped to v0.10.3.The monorepo version has been properly incremented and aligns with the coordinated release across all workspace packages.
packages/plugin-vite/package.json (1)
3-3: Plugin version correctly bumped to v0.10.3.The @jitar/plugin-vite package version has been properly incremented for publication.
examples/health-checks/package.json (1)
16-16: Version bump is correct and consistent.The jitar dependency is properly updated to v0.10.3.
examples/cors/package.json (1)
1-21: Version bump looks correct in isolation.The update to jitar v0.10.3 is applied correctly with valid JSON structure and appropriate devDependencies for the example package. Per repository patterns, examples properly declare their own devDependencies (rimraf, typescript, cpx2) rather than relying on workspace hoisting.
| # v0.10.3 | ||
| [2025-11-20] | ||
|
|
||
| ### Chores | ||
|
|
||
| * \[[717](https://github.com/MaskingTechnology/jitar/pull/717)] chore(deps): bump glob from 11.0.3 to 11.1.0 in /website (#717) by dependabot[bot] | ||
| * \[[711](https://github.com/MaskingTechnology/jitar/pull/711)] chore: replace changelog tool (#711) by Bas Meeuwissen | ||
|
|
There was a problem hiding this comment.
Fix markdown formatting violations that will fail linting.
The CHANGELOG has two style issues that violate markdown standards and will likely fail the CI pipeline:
- Line 1 (MD022): The
# v0.10.3heading must be surrounded by blank lines. Add a blank line before it. - Lines 1-4 (MD001): Heading hierarchy is broken. The file jumps from
# v0.10.3(h1) directly to### Chores(h3), skipping h2. Change### Choresto## Chores.
Apply this diff to fix both issues:
+
# v0.10.3
[2025-11-20]
-### Chores
+## Chores📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # v0.10.3 | |
| [2025-11-20] | |
| ### Chores | |
| * \[[717](https://github.com/MaskingTechnology/jitar/pull/717)] chore(deps): bump glob from 11.0.3 to 11.1.0 in /website (#717) by dependabot[bot] | |
| * \[[711](https://github.com/MaskingTechnology/jitar/pull/711)] chore: replace changelog tool (#711) by Bas Meeuwissen | |
| # v0.10.3 | |
| [2025-11-20] | |
| ## Chores | |
| * \[[717](https://github.com/MaskingTechnology/jitar/pull/717)] chore(deps): bump glob from 11.0.3 to 11.1.0 in /website (#717) by dependabot[bot] | |
| * \[[711](https://github.com/MaskingTechnology/jitar/pull/711)] chore: replace changelog tool (#711) by Bas Meeuwissen | |
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
1-1: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
4-4: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
🤖 Prompt for AI Agents
In CHANGELOG.md around lines 1 to 8, add a blank line before the top-level
heading so `# v0.10.3` is separated by an empty line, and change the `###
Chores` heading to `## Chores` to restore correct heading hierarchy (h1 -> h2);
make those two edits and save the file.
| }, | ||
| "dependencies": { | ||
| "jitar": "0.10.2" | ||
| "jitar": "0.10.3" |
There was a problem hiding this comment.
🧩 Analysis chain
Verify version consistency across the monorepo release.
The jitar dependency has been correctly updated to 0.10.3. However, ensure all related version references throughout the PR have been updated consistently (root package.json, other example packages, packages, CHANGELOG.md, and CLI version).
[/request_verification]
🏁 Script executed:
#!/bin/bash
# Description: Verify version consistency across the monorepo for v0.10.3 release
# Check: All version references should show 0.10.3 (not 0.10.2)
echo "=== Checking root package.json ==="
rg -A 2 '"version"' package.json | head -5
echo -e "\n=== Checking all example package.json files ==="
fd 'examples/.*/package.json' --exec rg -H '"jitar"' {}
echo -e "\n=== Checking packages directory ==="
fd 'packages/.*/package.json' --exec rg -H '"version"' {} | grep -E 'packages/(jitar|create-jitar|plugin-vite|cli)' | head -10
echo -e "\n=== Checking for remaining 0.10.2 references ==="
rg '0\.10\.2' --type json || echo "✓ No 0.10.2 references found in JSON files"
echo -e "\n=== Checking CLI version ==="
rg '0\.10\.3|0\.10\.2' packages/cli/src/commands/ShowVersion.ts || echo "⚠ ShowVersion.ts not found or version not detected"
echo -e "\n=== Checking CHANGELOG ==="
rg '0\.10\.3|0\.10\.2' CHANGELOG.md | head -5 || echo "⚠ CHANGELOG.md not found"Length of output: 693
The script output reveals an inconsistency: init templates still reference v0.10.2. Let me verify the complete scope of changes needed:
Now let me check if the init templates should be updated as part of this release:
Update init templates to v0.10.3—they still reference v0.10.2.
The monorepo version has been mostly updated to v0.10.3, but the user-facing init templates were missed:
packages/init/templates/react/package.jsonpackages/init/templates/vue/package.jsonpackages/init/templates/backend/package.json
These templates guide developers creating new projects and should reference the latest version.
🤖 Prompt for AI Agents
In examples/cors/package.json around line 19, the repo shows jitar at v0.10.3
while the init templates still reference v0.10.2; update the version strings in
the init templates to match the release by changing "jitar": "0.10.2" to
"jitar": "0.10.3" in packages/init/templates/react/package.json,
packages/init/templates/vue/package.json, and
packages/init/templates/backend/package.json (and regenerate or update any
template lockfiles if present) so new projects use v0.10.3 consistently.
| import ArgumentProcessor from '../ArgumentProcessor'; | ||
|
|
||
| const versionNumber = 'v0.10.2'; | ||
| const versionNumber = 'v0.10.3'; |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
LGTM! Version string updated correctly.
The version constant has been correctly updated to v0.10.3, matching the package version.
Optional: Consider dynamically importing version from package.json
To avoid manual updates in future releases, you could consider dynamically importing the version from package.json:
import { readFileSync } from 'fs';
import { join, dirname } from 'path';
import { fileURLToPath } from 'url';
const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);
const packageJson = JSON.parse(readFileSync(join(__dirname, '../../../package.json'), 'utf-8'));
const versionNumber = `v${packageJson.version}`;However, the current hardcoded approach is simpler and perfectly acceptable for a release process.
🤖 Prompt for AI Agents
In packages/cli/src/commands/ShowVersion.ts around line 5, the version is
hardcoded as 'v0.10.3'; to avoid manual updates, replace the constant with logic
that reads package.json at runtime and constructs the version string (prefixing
with 'v'), by resolving the package.json path relative to the module and parsing
its "version" field before exporting/using versionNumber; ensure this code works
in your build environment (ESM vs CJS) and falls back to the hardcoded string if
reading fails.



Fixes #718
Changes proposed in this pull request:
@MaskingTechnology/jitar