chore: setup publication flow #736
Conversation
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings. WalkthroughAdds a GitHub Actions "Publish packages" workflow and performs coordinated release updates: version bumps (v0.10.3 → v0.10.4), dependency bumps, package.json privacy flags, removal of a prepublish script, and expanded template rename guards/mappings. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant GH as GitHub Actions
participant Repo as Repository
participant Node as Node (runner)
participant NPM as npm Registry
rect rgb(230, 240, 255)
Note over GH,Repo: Trigger: workflow_dispatch
end
GH->>Repo: checkout code
GH->>Node: setup Node.js v24 (actions/setup-node)
GH->>Node: npm ci (install)
Node->>Repo: run npm run build (build packages)
Node->>Repo: run npm run publish-jitar
Node->>NPM: publish jitar package
alt plugin publish
Node->>Repo: run npm run publish-plugin
Node->>NPM: publish plugin package
end
GH->>GH: echo "Done publishing packages"
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks✅ Passed checks (3 passed)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: Organization 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 (16)
.github/workflows/publish.ymlpackage.jsonpackages/cli/src/commands/ShowVersion.tspackages/create-jitar/package.jsonpackages/http/package.jsonpackages/init/src/InitManager.tspackages/init/templates/backend/_package.jsonpackages/init/templates/backend/_tsconfig.jsonpackages/init/templates/react/_package.jsonpackages/init/templates/react/_tsconfig.jsonpackages/init/templates/react/_vite.config.tspackages/init/templates/vue/_package.jsonpackages/init/templates/vue/_tsconfig.jsonpackages/init/templates/vue/_vite.config.tspackages/jitar/package.jsonpackages/plugin-vite/package.json
🧰 Additional context used
🧠 Learnings (4)
📚 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:
packages/http/package.jsonpackages/jitar/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:
packages/http/package.jsonpackage.jsonpackages/create-jitar/package.jsonpackages/jitar/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: 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:
packages/create-jitar/package.jsonpackages/jitar/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:
packages/jitar/package.json
🔇 Additional comments (8)
packages/cli/src/commands/ShowVersion.ts (1)
5-5: LGTM! Version bump is consistent with the release.The version update from v0.10.3 to v0.10.4 aligns with the version bumps across other packages in this PR.
packages/init/src/InitManager.ts (1)
14-20: LGTM! Template file mappings are well-structured.The addition of
_package.json,_tsconfig.json, and_vite.config.tsmappings enables template initialization to properly rename configuration files without conflicting with the monorepo structure. The#renameFilesmethod will correctly handle these new mappings.packages/jitar/package.json (2)
3-3: LGTM! Version bump and publication configuration are correct.The version update to 0.10.4 and the addition of
"private": falsealign with the publication flow setup objective.Also applies to: 10-10
34-34: Verify the express dependency update.The express version bump from 5.1.0 to 5.2.1 should be verified for compatibility and security (same verification needed as in packages/http/package.json).
packages/create-jitar/package.json (1)
7-7: LGTM! Deprecation configuration is correct.Marking the package as
private: trueand removing theprepublishOnlyscript aligns with the package being deprecated (as noted in the description). This prevents accidental publication while keeping the package available for internal use.Also applies to: 32-32
package.json (1)
26-38: LGTM! DevDependency updates are appropriate.All updates are minor or patch version bumps (eslint, typescript-eslint, vitest, turbo), which is consistent with routine maintenance. No breaking changes are expected from these updates.
packages/plugin-vite/package.json (1)
31-31: Vite 7.2.6 dependency is valid.Verification confirms that vite 7.2.6 is a stable, released version. The caret range (^7.2.6) allows compatible updates up to vite 7.3.0, the latest stable release in the 7.x series.
packages/http/package.json (1)
25-25: Express 5.2.1 is a valid, stable version with no known security vulnerabilities.The npm registry confirms 5.2.1 is available and released. Snyk vulnerability database shows no active security issues for this version. A prototype-pollution vulnerability (CVE-2024-51999) that existed in earlier 5.x releases was patched in 5.2.0, so 5.2.1 includes the fix.
| - name: 🔨 Build all packages | ||
| run: npm run build |
There was a problem hiding this comment.
Misleading comment: Build is selective, not all packages.
The comment states "Build all packages" but the npm run build command (defined in root package.json line 13) only builds selected packages: jitar, create-jitar, and @jitar/plugin*. Consider updating the comment to reflect the actual behavior or use npm run build:all if all packages should be built.
🔎 Suggested fix
- - name: 🔨 Build all packages
+ - name: 🔨 Build packages for publication
run: npm run build📝 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.
| - name: 🔨 Build all packages | |
| run: npm run build | |
| - name: 🔨 Build packages for publication | |
| run: npm run build |
🤖 Prompt for AI Agents
.github/workflows/publish.yml around lines 26-27: the step comment "🔨 Build all
packages" is misleading because the root npm run build only builds selected
packages (jitar, create-jitar, and @jitar/plugin*); update the comment to
reflect that it builds only those packages (e.g., "🔨 Build selected packages
(jitar, create-jitar, @jitar/plugin*)") or change the command to npm run
build:all if you intend to build every package; ensure the comment and command
are consistent.
|
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
packages/init/src/InitManager.ts
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: basmasking
Repo: MaskingTechnology/jitar PR: 736
File: .github/workflows/publish.yml:29-33
Timestamp: 2025-12-27T20:44:56.863Z
Learning: npm supports OIDC publishing from GitHub Actions without requiring NODE_AUTH_TOKEN or npm access tokens when using trusted publishing. Required setup: permissions.id-token: write and contents: read, actions/setup-node with registry-url configured, and npm >= 11.5.1 (bundled with modern Node.js versions).
🔇 Additional comments (2)
packages/init/src/InitManager.ts (2)
2-2: LGTM: Import additions support the new file existence check.The addition of
existsSyncand thefspalias for fs promises are appropriate for the defensive file renaming logic introduced later in the file.
14-20: LGTM: Template file mappings are comprehensive and follow the correct pattern.The expanded
RENAME_FILESmapping now includes essential configuration files (package.json,tsconfig.json,vite.config.ts) alongside.gitignore. The underscore prefix convention correctly prevents these template files from being interpreted as active configuration during template storage.
| if (existsSync(sourceFileLocation)) | ||
| { | ||
| promises.push(fsp.rename(sourceFileLocation, targetFileLocation)); | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
LGTM: Defensive check prevents errors when template files are missing.
The existsSync guard correctly prevents rename errors when source files don't exist, allowing templates to optionally include these configuration files. This aligns well with the PR objective.
Optional consideration: For full async consistency, you could replace existsSync with fsp.access(), though the current synchronous check is pragmatic and widely used for this pattern.
🔎 Optional async alternative (fully async pattern)
for (const [source, target] of files)
{
const sourceFileLocation = path.join(projectLocation, source);
const targetFileLocation = path.join(projectLocation, target);
- if (existsSync(sourceFileLocation))
- {
- promises.push(fsp.rename(sourceFileLocation, targetFileLocation));
- }
+ promises.push(
+ fsp.access(sourceFileLocation)
+ .then(() => fsp.rename(sourceFileLocation, targetFileLocation))
+ .catch(() => {}) // Silently skip if file doesn't exist
+ );
}📝 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.
| if (existsSync(sourceFileLocation)) | |
| { | |
| promises.push(fsp.rename(sourceFileLocation, targetFileLocation)); | |
| } | |
| promises.push( | |
| fsp.access(sourceFileLocation) | |
| .then(() => fsp.rename(sourceFileLocation, targetFileLocation)) | |
| .catch(() => {}) // Silently skip if file doesn't exist | |
| ); |
🤖 Prompt for AI Agents
In packages/init/src/InitManager.ts around lines 106 to 109, replace the
synchronous existsSync guard with an asynchronous check using fsp.access (or
fsp.stat) to keep the I/O fully async: attempt to await
fsp.access(sourceFileLocation) inside a try/catch and only push the fsp.rename
promise when access succeeds, swallow or ignore the not-found error in the catch
so missing template files remain optional.
Fixes #
Changes proposed in this pull request:
@MaskingTechnology/jitar