Repository navigation
Conversation
Kitty Graphics Protocol renderer sent both c (columns) and r (rows) in the same escape sequence, which stretches the image to fill that exact cell box instead of preserving aspect ratio. Only c is now sent, letting the terminal auto-compute rows from the image's real aspect ratio, and cursor movement uses the protocol default (C=0) instead of a hardcoded single-line advance. Also migrates publish.yml to OIDC trusted publishing (npm stage publish), matching js-recon's release pipeline.
|
Warning Review limit reached
Next review available in: 53 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe Kitty renderer now receives only target columns and lets the terminal calculate image height. The package version is 1.1.1. npm publishing now uses OIDC and staged publication with manual approval. ChangesRenderer and release update
Estimated code review effort: 3 (Moderate) | ~20 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/publish.yml:
- Line 62: Update the actions/checkout@v4 step in the publish job to set
persist-credentials to false, leaving the existing checkout behavior otherwise
unchanged.
- Around line 65-69: Update the staging workflow around the Node setup and
“Ensure npm CLI supports OIDC trusted publishing” step to pin Node to a tested
22.14.0-or-newer version and npm to a tested npm 11.15.0-or-newer release
instead of npm@latest. Add a version diagnostic command immediately before npm
stage publish that logs the resolved Node and npm versions.
In `@CLAUDE.md`:
- Line 32: Update the native-protocol sizing documentation near the statement
that both target_cols and target_char_rows are passed universally: explicitly
state that Kitty receives only target_cols, while iTerm2 continues to receive
both dimensions. Keep the existing renderKitty contract and other protocol
descriptions unchanged.
- Line 57: Update the npm trusted-publishing instructions near the existing
`@shriyanss/cli-print-img`, repository, and publish.yml configuration to specify
the allowed action as stage-only for npm stage publish. Also instruct
maintainers to verify this permission before releasing.
In `@package.json`:
- Line 3: Add a repository metadata entry in package.json pointing to the GitHub
repository shriyanss/client-print-img, keeping the existing version value at
1.1.1.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 4aa4a0d9-1325-49aa-a86e-d88adcf64c72
📒 Files selected for processing (6)
.github/workflows/publish.ymlCHANGELOG.mdCLAUDE.mdindex.jspackage.jsonrenderers/kitty.js
| node-version: "22" | ||
| registry-url: https://registry.npmjs.org/ | ||
| - run: npm ci | ||
| - name: Publish to npm | ||
| - name: Ensure npm CLI supports OIDC trusted publishing | ||
| run: npm install -g npm@latest |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow excerpt =="
wc -l .github/workflows/publish.yml
sed -n '1,130p' .github/workflows/publish.yml
echo
echo "== npm latest registry metadata =="
python3 - <<'PY'
import urllib.request as ureq
import json
url = "https://registry.npmjs.org/npm/latest"
with ureq.urlopen(url, timeout=20) as r:
data = json.load(r)
print(json.dumps({
"version": data.get("version"),
"engines": data.get("engines"),
"gitHead": data.get("gitHead"),
"homepage": data.get("homepage"),
}, indent=2))
PY
echo
echo "== parse package versions/versions with engines if requested =="
python3 - <<'PY'
import urllib.request as ureq
import json
import re
url = "https://registry.npmjs.org/npm/latest"
with ureq.urlopen(url, timeout=20) as r:
data = json.load(r)
version = data["version"]
# Fetch a specific major/minor close to referenced values using a manifest is not reliably available.
# Use simple regex probe to parse engines from the latest response.
print("latest_version", version)
engines = data.get("engines", {}) or {}
node_raw = engines.get("node", "")
npm_latest = data.get("latest", {})
print("engines", engines)
def parse_semver_tuple(s):
return tuple(int(x) for x in re.split(r"[^\d]+", s.strip())[:3])
def parse_engine(s):
# simple parser for examples like ^22.22.2 || ^24.15.0 || >=26.0.0
constraints = re.split(r"\s*\|\|\s*", s.strip())
out = []
for c in constraints:
c = c.strip()
if not c:
continue
if c.startswith("^"):
base = parse_semver_tuple(c[1:])
out.append((base[0], base[1], base[2], ">=base", base))
elif c.startswith(">="):
base = parse_semver_tuple(c[2:])
out.append((base[0], base[1], base[2], ">=base", base))
else:
base = parse_semver_tuple(c)
out.append((base[0], base[1], base[2], "exact", base))
return out
node_range = parse_engine(node_raw)
print("node_range", node_range)
print("node_range_max_base", max(node_range, key=lambda x: x[4]) if node_range else None)
PY
echo
echo "== search for version checks/tests in workflow =="
rg -n "npm audit|npm test|version|set-output|run: .*version|TAG|publish|npm .* publish" .github/workflows/publish.yml package.json CHANGELOG.md || trueRepository: shriyanss/cli-print-img
Length of output: 6362
🌐 Web query:
npm staging publish requires npm 11.15.0 Node 22.14.0
💡 Result:
Yes, staged publishing on npm requires npm CLI version 11.15.0 or higher and Node.js version 22.14.0 or higher [1][2]. Staged publishing is a feature that allows you to submit a package version to a staging area for review before it is made publicly available [1][2]. This process is designed to improve security in automated workflows by allowing CI systems to stage a package without requiring two-factor authentication (2FA) [1][3]. A maintainer can subsequently review the staged package and explicitly approve it—a step that does require 2FA—before it is published to the registry [1][4][5]. To use this feature, ensure your environment meets the minimum version requirements specified above [1][2]. You can check your current version using the command npm --version and node --version. If you need to update your npm CLI, you can generally do so using the command npm install -g npm@latest.
Citations:
- 1: https://docs.npmjs.com/staged-publishing/
- 2: https://github.blog/changelog/2026-05-22-staged-publishing-and-new-install-time-controls-for-npm/
- 3: feat: npm stage npm/cli#9201
- 4: https://docs.npmjs.com/creating-and-publishing-unscoped-public-packages/
- 5: https://docs.npmjs.com/creating-and-publishing-scoped-public-packages/
🌐 Web query:
npm 12 engines node 22.22.2 24.15.0 26.0.0
💡 Result:
As of August 10, 2026, the current version of npm is 12.0.2, which was released on July 27, 2026 [1][2]. Beginning with npm v12.0.0, the CLI officially supports Node.js versions defined by the range ^22.22.2 || ^24.15.0 || >=26.0.0 [3][4]. This requirement is specified in the engine compatibility settings for the npm package itself [3][4]. The engines field in a package.json file allows developers to specify which versions of Node.js and npm their project is compatible with [5][6]. This setting is advisory and produces warnings during installation if the environment does not match the specified range, unless the user explicitly enables strict engine checking (e.g., via the engine-strict configuration flag) [5][7].
Citations:
- 1: https://docs.npmjs.com/cli/v12/using-npm/changelog/
- 2: deps: upgrade npm to 12.0.2 nodejs/node#64882
- 3: https://github.com/npm/cli/blob/master/CHANGELOG.md
- 4: https://github.com/npm/cli/releases/tag/v12.0.0
- 5: https://docs.npmjs.com/cli/v12/configuring-npm/package-json/
- 6: https://docs.npmjs.com/cli/v10/configuring-npm/package-json/
- 7: https://stackoverflow.com/questions/29349684/how-can-i-specify-the-required-node-js-version-in-package-json
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== current npm metadata using curl with explicit TLS settings from proxy if any =="
curl -fsSL --retry 3 --connect-timeout 10 "https://registry.npmjs.org/npm/latest" | python3 - <<'PY'
import sys, json
data=json.load(sys.stdout)
print(json.dumps({"version": data.get("version"), "engines": data.get("engines")}, indent=2))
PY
echo
echo "== exact npm 12.0.2 engine field from package registry =="
curl -fsSL --retry 3 --connect-timeout 10 "https://registry.npmjs.org/npm/12.0.2" | python3 - <<'PY'
import sys, json
data=json.load(sys.stdout)
print(json.dumps({"version": data.get("version"), "engines": data.get("engines")}, indent=2))
PY
echo
echo "== package.json engine requirements =="
cat package.json | python3 - <<'PY'
import json, sys
data=json.load(sys.stdout)
print(json.dumps({"engines": data.get("engines")}, indent=2))
PY
echo
echo "== npm and node version logging in workflow =="
rg -n "node --version|npm --version|npm install -g npm|stage publish|setup-node" .github/workflows/publish.yml .package-lock.json package.json 2>/dev/null || trueRepository: shriyanss/cli-print-img
Length of output: 523
🌐 Web query:
npm 12.0.2 engines node range npm package.json
💡 Result:
npm version 12.0.2 was released on July 27, 2026 [1][2]. Regarding the engines field in package.json for npm 12, npm requires specific versions of Node.js to run. As of recent updates within the v12 development cycle, npm supports the following Node.js engine range: ^22.22.2 || ^24.15.0 || >=26.0.0 [3][4]. To specify the Node.js version requirements for your own project in your package.json file, you use the engines field [5]: { "engines": { "node": "^22.22.2 || ^24.15.0 || >=26.0.0" } } The engines field is advisory; npm will only issue a warning if the installed version of Node.js does not satisfy the specified range, unless the user has explicitly enabled the engine-strict configuration flag [5].
Citations:
- 1: https://docs.npmjs.com/cli/v12/using-npm/changelog/
- 2: https://github.com/npm/cli/releases
- 3: https://github.com/npm/cli/blob/latest/CHANGELOG.md
- 4: npm/cli@2dd1434
- 5: https://docs.npmjs.com/cli/v12/configuring-npm/package-json/
🌐 Web query:
npm staging publish npm 11.15.0 Node 22.14.0 documentation
💡 Result:
Staged publishing is an npm feature that introduces an approval step before a package is made available on the registry [1]. This workflow allows you to stage a package for publication without requiring two-factor authentication (2FA) immediately, making it particularly useful for automated CI/CD workflows where injecting 2FA is difficult [2][3]. Requirements Staged publishing requires npm CLI version 11.15.0 or later and Node.js version 22.14.0 or higher [1]. Additionally, you must have publish access to the package, the package must already exist on the npm registry (you cannot use this for new packages), and 2FA must be enabled on your npm account [1]. Workflow Steps 1. Stage a Package: Run the following command in your package's root directory to submit it to the staging area: npm stage publish This step does not require 2FA [1][2]. 2. Review a Package: You can inspect the staged package using the CLI (via npm stage list and npm stage view) or via the Staged Packages tab on npmjs.com [1][2][3]. 3. Approve and Publish: To make the package publicly available, a maintainer must approve it using 2FA, either via the CLI or npmjs.com [1]. To approve via the CLI: npm stage approve You will be prompted for 2FA verification regardless of whether you approve the package in the CLI or on npmjs.com [1][3]. Note that staged publishing is distinct from direct publishing (npm publish) and serves as an alternative for maintainers who wish to require human verification for releases [1][3].
Citations:
- 1: https://docs.npmjs.com/staged-publishing/
- 2: https://docs.npmjs.com/cli/v12/commands/npm-stage/
- 3: https://docs.npmjs.com/creating-and-publishing-unscoped-public-packages/
Pin the staging runtime versions to a tested compatible pair.
npm install -g npm@latest depends on a moving npm major; staged publishing requires npm 11.15.0+ and Node 22.14.0+, but the workflow uses generic Node 22. Pin the npm major or a tested npm 11 release, and log the resulting Node/npm versions before npm stage publish.
🧰 Tools
🪛 zizmor (1.29.0)
[warning] 69-69: ad-hoc installation of packages (adhoc-packages): installs a package outside of a lockfile
(adhoc-packages)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/publish.yml around lines 65 - 69, Update the staging
workflow around the Node setup and “Ensure npm CLI supports OIDC trusted
publishing” step to pin Node to a tested 22.14.0-or-newer version and npm to a
tested npm 11.15.0-or-newer release instead of npm@latest. Add a version
diagnostic command immediately before npm stage publish that logs the resolved
Node and npm versions.
Sources: MCP tools, Linters/SAST tools
| { | ||
| "name": "@shriyanss/cli-print-img", | ||
| "version": "1.1.0", | ||
| "version": "1.1.1", |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Files:\n'
git ls-files | sed -n '1,120p'
printf '\npackage.json:\n'
cat -n package.json | sed -n '1,220p'
printf '\nWorkflow files:\n'
git ls-files | rg '(^|/)(\.github/workflows/.*\.ya?ml|.*Trusted|npm|package)' || true
printf '\nSearch repository trust/publish config:\n'
rg -n "repository|trusted-publish|npmjs|npm stage publish|Trusted|npm publish|github\.com/shriyanss/cli-print-img" -S . -g '!node_modules' -g '!dist' -g '!build' || trueRepository: shriyanss/cli-print-img
Length of output: 9770
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
import json
from pathlib import Path
p = Path('package.json')
data = json.loads(p.read_text())
print("name", data.get("name"))
print("version", data.get("version"))
print("repository", data.get("repository"))
expected = f"https://github.com/{data.get('name','').removeprefix('@')}".replace('/', '/').removesuffix('/')
print("simple-expected-url-like GitHub", expected)
PYRepository: shriyanss/cli-print-img
Length of output: 296
🌐 Web query:
npm GitHub Actions Trusted Publishing requires package.json repository field
💡 Result:
Yes, configuring the repository field in your package.json is a critical requirement for using npm Trusted Publishing with GitHub Actions [1][2]. To successfully publish packages using OIDC (Trusted Publishing), the repository.url field in your package.json must exactly match your GitHub repository [1][2][3]. If these do not align, your publish attempt will fail [2][3]. Key details regarding this requirement include: 1. Consistency: npm validates that the repository defined in your package.json matches the repository detected by the GitHub OIDC token [1][3]. This prevents unauthorized or misconfigured publishes, such as from a fork that has not updated its package.json to match the new origin [1][2]. 2. Format: The repository field must be accurately formatted, typically as an HTTPS URL (e.g., "https://github.com/owner/repo") [3]. Including prefixes like git+ or suffixes like.git can sometimes cause mismatches depending on how the comparison is performed; ensuring an exact match with your GitHub repository identity is essential [3]. 3. Monorepos: If your package resides in a monorepo, you must also include the directory field within the repository object in your package.json to ensure the path is correctly identified [3]. 4. Validation Timing: Importantly, npm does not validate this configuration when you first save your Trusted Publisher settings on npmjs.com [2]. The requirement is enforced during the actual publish process; if there is a mismatch, you will encounter an error (often a 422 Unprocessable Entity related to provenance or OIDC verification) when the workflow attempts to run [2][3]. While the repository field is also required if you choose to use the --provenance flag during publication, it is a prerequisite for Trusted Publishing itself to ensure the identity of the publishing repository is verified [3][4].
Citations:
- 1: https://docs.npmjs.com/trusted-publishers/
- 2: https://github.com/npm/documentation/blob/main/content/packages-and-modules/securing-your-code/trusted-publishers.mdx
- 3: https://leechael.org/posts/2025/npm-trusted-publishers-the-complete-guide/
- 4: https://github.com/simonw/til/blob/main/npm/npm-publish-github-actions.md
Add package repository metadata for OIDC Trusted Publishing.
npm stage publish uses GitHub OIDC Trusted Publishing, which requires repository.url in package.json to match the GitHub repository. Add the shriyanss/client-print-img repository URL before staging the release; the release version field can remain 1.1.1 for a patch release.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@package.json` at line 3, Add a repository metadata entry in package.json
pointing to the GitHub repository shriyanss/client-print-img, keeping the
existing version value at 1.1.1.
Source: MCP tools
- Add package.json repository field, required for npm OIDC trusted publishing to verify against the GitHub Actions OIDC token - Set persist-credentials: false on the publish-npm job's checkout (not needed since no authenticated git commands run there) - Fix CLAUDE.md sizing-contract doc (Kitty only receives target_cols) and clarify the Trusted Publisher config needs "npm stage publish" scope specifically
1 participant
1.1.1 - 2026-08-10
Fixed
c(columns) andr(rows) in the same escape sequence, which stretches the image to exactly fill that cell box instead of preserving its aspect ratio — producing a visibly distorted logo in Kitty/Ghostty. Onlycis now sent, letting the terminal auto-compute rows from the image's real aspect ratio (matching how the iTerm2 renderer already usespreserveAspectRatio=1).C=1) and unconditionally advanced a single line afterward, which assumed a fixed, known row count. Now uses the protocol default (C=0) so the terminal itself advances the cursor by however many rows the image actually rendered, fixing overlap with subsequent output.Also migrates
.github/workflows/publish.ymlto OIDC trusted publishing (npm stage publish), matching js-recon's release pipeline. Requires the npm Trusted Publisher to be configured for this package/workflow before this release goes out, or thepublish-npmjob will fail.Fixes js-recon/js-recon-internal-docs#159
Summary by CodeRabbit