feat: updated release implementation for neovim config #20
Conversation
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. 📝 WalkthroughSummary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings. WalkthroughAdds automated release tooling and CI, introduces a bloat analysis generation step and plugin entry, updates editor/format configs and ignore patterns, adds new Makefile target, and adjusts package scripts and devDependencies for release automation and commit linting. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant GH as GitHub Actions
participant Runner as CI Runner
participant Make as Makefile
participant NVim as Neovim (headless)
participant Auto as auto (release)
GH->>Runner: trigger on push/PR
Runner->>Runner: checkout repo
Runner->>Runner: setup pnpm & Node
Runner->>Runner: install dependencies
Runner->>Runner: build (TypeScript)
Runner->>Make: run `make generate-bloat`
Make->>NVim: launch headless with config\n+"Bloat bloat.json"
NVim-->>Make: write `bloat.json` to repo root
Make-->>Runner: finish
Runner->>Auto: run `pnpm run release` (auto shipit)
Auto-->>Runner: create tags/releases, upload assets (uses .autorc)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Poem
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
Summary of ChangesHello @stephansama, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the development and release pipeline for the Neovim configuration. It establishes an automated release system to simplify version management and asset distribution, while also introducing a mechanism to analyze and monitor the configuration's size. Complementary tooling adjustments ensure consistent code formatting and adherence to commit message conventions, contributing to a more robust and maintainable codebase. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request sets up an automated release process using auto-it and introduces a mechanism to analyze Neovim's startup "bloat". The changes include adding configuration for auto-it, a new Makefile target to generate bloat data, and updating the build scripts and dependencies accordingly. My main feedback is a critical security concern regarding personal information being hardcoded in the new .autorc file. I've also included a minor suggestion to improve dependency management consistency in package.json. Overall, the changes are well-aligned with the goal of automating releases.
| "name": "Stephan Randle", | ||
| "email": "[email protected]" |
There was a problem hiding this comment.
Hardcoding personal information like your name and email address in a configuration file within a public repository is a significant security and privacy risk. This information can be scraped by bots and used for spam, phishing, or other malicious activities. It's recommended to remove this information from the repository. If this information is required by the auto tool, consider using environment variables or a local, untracked configuration file to provide it.
| "prettier": "^3.6.2", | ||
| "prettier-plugin-organize-imports": "^4.2.0", | ||
| "prettier-plugin-sort-package-json": "^1.1.0", | ||
| "prettier-plugin-packagejson": "2.5.20", |
There was a problem hiding this comment.
The version for prettier-plugin-packagejson is pinned (2.5.20), while most other dependencies in this file use a caret ^ for version ranges (e.g., ^11.3.6). For consistency and to allow for non-breaking patch and minor updates, you might want to use a caret for this dependency as well. If pinning this specific version is intentional to prevent breakages, consider adding a comment to explain why.
| "prettier-plugin-packagejson": "2.5.20", | |
| "prettier-plugin-packagejson": "^2.5.20", |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
lua/plugins/debug/bloat.js (2)
20-24: Add error handling for file I/O and JSON parsing.The script lacks error handling for critical operations:
- Reading
bloat.json(could fail if file doesn't exist)- JSON parsing (could fail with malformed JSON)
- Writing output file (could fail due to permissions or disk space)
These failures will produce cryptic error messages instead of user-friendly diagnostics.
🔎 Proposed enhancement
+try { + if (!fs.existsSync(input)) { + console.error(`Input file not found: ${input}`); + process.exit(1); + } + const bloat = await fsp.readFile(input, { encoding: "utf8" }); - const bloatJson = JSON.parse(bloat); - await fsp.writeFile(output, JSON.stringify(removePrefix(bloatJson))); + console.log(`Successfully processed bloat data to ${output}`); +} catch (error) { + console.error("Failed to process bloat data:", error.message); + process.exit(1); +}
26-34: Consider non-mutating transformation (optional).The
removePrefixfunction mutates the input object. While this works for the current use case, a non-mutating approach would be more predictable and align with functional programming best practices.🔎 Alternative non-mutating implementation
function removePrefix(obj) { + const result = {}; for (const [key, value] of Object.entries(obj)) { - if (typeof value !== "object") continue; - delete obj[key]; const newKey = key.replace(/^.*\.local\/share\/nvim\/lazy\//g, ""); - obj[newKey] = removePrefix(value); + result[newKey] = typeof value === "object" ? removePrefix(value) : value; } - return obj; + return result; }
♻️ Duplicate comments (2)
.autorc (1)
14-15: Security concern: Personal information exposed in public repository.This concern was previously raised. The hardcoded name and email in a public repository configuration file poses privacy and security risks. Consider using environment variables (e.g.,
AUTO_NAME,AUTO_EMAIL) or a local, untracked configuration file if theautotool supports it.package.json (1)
70-70: Version pinning inconsistency (previously flagged).This was previously noted. The pinned version
2.5.20(without caret) is inconsistent with other dependencies that use caret ranges. Consider using^2.5.20for consistency unless there's a specific reason to pin this exact version.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (11)
.autorc.editorconfig.github/workflows/release.yaml.gitignore.prettierignoreMakefiledictionary/words.txtlazy-lock.jsonlua/plugins/debug/bloat.jslua/plugins/enabled.tspackage.json
🔇 Additional comments (14)
.prettierignore (1)
5-5: LGTM!Adding
.editorconfigto the Prettier ignore list is appropriate, as EditorConfig files have their own formatting conventions that should not be altered by Prettier..autorc (1)
1-11: LGTM!The plugin configuration is correctly set up with appropriate auto plugins for release automation. The asset path
./dist/bloat.jsonaligns with the Makefile target that generates this file..editorconfig (1)
14-14: LGTM!Expanding the 2-space indentation rule to include YAML and YML files is appropriate and follows common conventions for these file formats.
.gitignore (2)
4-6: LGTM!Adding
bloat.json,deps, anddistto gitignore is appropriate. These are build artifacts generated by the new Makefile target and should not be tracked in version control.
15-18: LGTM!Replacing explicit file ignores with wildcard patterns (
lua/schemas/*.json,lua/schemas/*.lua, etc.) improves maintainability and automatically covers future generated files in these directories.package.json (4)
38-46: LGTM!The Prettier override for
.autorcis necessary and correct, as this file contains JSON but lacks a.jsonextension. This ensures Prettier can properly format the file.
10-10: LGTM!The new scripts are correctly configured:
build:schemafor schema generationreleaseintegrating with the auto toolsnippets:mergefor snippet managementAlso applies to: 17-18
50-52: LGTM!The auto-it dependencies are correctly added with consistent versions and align with the plugin configuration in
.autorc. The@manypkg/find-rootpackage appears to support the bloat.js root-aware path resolution mentioned in the AI summary.Also applies to: 59-59, 61-61
25-29: The lint-staged configuration with the"*"pattern is appropriate for this repository. Both Prettier and ESLint have built-in filtering mechanisms:
- Prettier respects
.prettierignore, which excludes text files (*.txt), config files, and other non-code files- ESLint's configuration specifies exact file types to process:
**/*.{js,mjs,cjs,ts,mts,cts},**/*.json*, and**/*.mdThe repository contains no binary files, only text-based source code and configuration. The tools will skip files outside their scope automatically.
lua/plugins/enabled.ts (1)
4-4: LGTM!Adding
"debug.bloat"to the enabled plugins list correctly integrates the new bloat.nvim plugin referenced in lazy-lock.json and used by the Makefile target.lazy-lock.json (1)
26-29: bloat.nvim entry is correct and verified.The bloat.nvim plugin is a legitimate, established Neovim plugin maintained by dundalek that analyzes and visualizes installed-plugin code sizes. The commit hash
f90bef655ac40fecbaae53e10db1cf7894d090b1is valid and exists in the repository..github/workflows/release.yaml (2)
2-9: Verify dual-trigger release workflow is intentional.The workflow triggers on both push to
mainand pull request events. Typically, release workflows only run on push to the main branch to avoid unintended release attempts from PRs. Confirm this is the intended behavior.
20-31: LGTM!The checkout, dependency management, and build steps are properly configured. Using
.nvmrcfor Node version management and pnpm caching are good practices.lua/plugins/debug/bloat.js (1)
15-18: Verify early exit behavior is appropriate for CI.The script exits early if the output file already exists. In the CI workflow (
.github/workflows/release.yaml), this could skip regeneration if the file is cached or left over from a previous run, potentially using stale data. Consider whether regeneration should be forced in CI or if a warning should be logged.
| env: | ||
| LUA_LS_VERSION: 3.7.4 |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Remove unused environment variable.
The LUA_LS_VERSION environment variable is defined but not used anywhere in the workflow. Consider removing it to keep the configuration clean.
🤖 Prompt for AI Agents
.github/workflows/release.yaml around lines 10 to 11 defines an unused
environment variable LUA_LS_VERSION; remove the LUA_LS_VERSION entry from the
env block (or the entire env block if it becomes empty) to keep the workflow
configuration clean and avoid unused configuration.
| concurrency: | ||
| group: github.head_ref | ||
| cancel-in-progress: true |
There was a problem hiding this comment.
Fix concurrency group to handle both push and PR events.
The concurrency group uses github.head_ref, which is only defined for pull_request events. For push events (including pushes to main), this will be empty, causing all push runs to share the same concurrency group and potentially cancel each other unexpectedly.
🔎 Proposed fix
concurrency:
- group: github.head_ref
+ group: ${{ github.head_ref || github.ref }}
cancel-in-progress: true📝 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.
| concurrency: | |
| group: github.head_ref | |
| cancel-in-progress: true | |
| concurrency: | |
| group: ${{ github.head_ref || github.ref }} | |
| cancel-in-progress: true |
🤖 Prompt for AI Agents
In .github/workflows/release.yaml around lines 12-14, the concurrency group
currently uses github.head_ref which is undefined for push events; replace it
with a deterministic expression that works for both PRs and pushes, for example
set group to an expression combining the workflow and either head_ref or ref
(e.g. ${{ github.workflow }}-${{ github.head_ref || github.ref }}), so push runs
use the branch ref and PR runs use the head_ref and runs don’t inadvertently
share/cancel each other.
| - name: Run release | ||
| run: pnpm run release |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's see the full context of the workflow file around line 39-40
head -50 .github/workflows/release.yamlRepository: stephansama/nvim
Length of output: 978
🏁 Script executed:
# Check package.json for the release script
cat package.json | jq '.scripts.release' 2>/dev/null || cat package.json | grep -A 2 '"release"'Repository: stephansama/nvim
Length of output: 73
🏁 Script executed:
# Search for release tool configurations
fd -t f '(autorc|\.release-it|semantic-release)' -E node_modules 2>/dev/null
ls -la | grep -i auto 2>/dev/nullRepository: stephansama/nvim
Length of output: 119
🏁 Script executed:
# Check the .autorc configuration
cat .autorcRepository: stephansama/nvim
Length of output: 301
🏁 Script executed:
# Check if there are any environment variables set in the release job
grep -A 20 "jobs:" .github/workflows/release.yaml | grep -E "(env:|GITHUB|NPM|TOKEN)"Repository: stephansama/nvim
Length of output: 42
🏁 Script executed:
# Check if secrets are referenced anywhere in the workflow
grep -r "secrets\." .github/workflows/release.yamlRepository: stephansama/nvim
Length of output: 42
🏁 Script executed:
# Look for any GitHub Actions documentation or setup in other workflow files
find .github/workflows -name "*.yaml" -o -name "*.yml" | head -5Repository: stephansama/nvim
Length of output: 90
🏁 Script executed:
# Check if the workflow specifies permissions for the job
grep -B 10 "release:" .github/workflows/release.yaml | grep -E "(permissions|contents)"Repository: stephansama/nvim
Length of output: 42
🏁 Script executed:
# Look for any other release workflows that might have the proper setup
find .github -name "*.yaml" -o -name "*.yml" | xargs grep -l "auto shipit" 2>/dev/nullRepository: stephansama/nvim
Length of output: 44
🏁 Script executed:
# Check if there's documentation or CI config that shows how auto is being used
find . -maxdepth 2 -type f \( -name "*.md" -o -name ".github" -type d \) | head -10Repository: stephansama/nvim
Length of output: 71
🏁 Script executed:
# Verify the auto tool requirements - check node_modules or package.json for auto
cat package.json | jq '.devDependencies, .dependencies' | grep -i autoRepository: stephansama/nvim
Length of output: 198
🏁 Script executed:
# Check the full job definition for permissions
cat .github/workflows/release.yaml | grep -A 30 "jobs:"Repository: stephansama/nvim
Length of output: 769
🏁 Script executed:
# Look at the README to see if there's any documentation about the release process
cat README.md | grep -A 10 -B 5 -i "release\|auto"Repository: stephansama/nvim
Length of output: 1356
🏁 Script executed:
# Check if GITHUB_TOKEN is typically needed for auto - look at GitHub Actions context
# In GitHub Actions, GITHUB_TOKEN is automatically available, but we need to verify
# if it's being passed correctly. Let's check the step more carefully.
grep -A 5 -B 5 "pnpm run release" .github/workflows/release.yamlRepository: stephansama/nvim
Length of output: 232
🏁 Script executed:
# Let's check if there's any documentation about auto and GitHub Actions
# Search for any GitHub Actions specific setup in the repo
find . -name "*.md" -o -name "*.txt" | xargs grep -l "GITHUB_TOKEN\|GH_TOKEN\|NPM_TOKEN" 2>/dev/nullRepository: stephansama/nvim
Length of output: 44
🏁 Script executed:
# Check if setup-node with registry-url automatically sets NPM_TOKEN
# Also check if there's a .npmrc file
ls -la .npmrc 2>/dev/null || echo "No .npmrc found"
cat .npmrc 2>/dev/null || echo "No .npmrc to display"Repository: stephansama/nvim
Length of output: 96
🏁 Script executed:
# Let's examine what permissions the checkout action needs
grep -A 10 "actions/checkout" .github/workflows/release.yamlRepository: stephansama/nvim
Length of output: 419
🏁 Script executed:
# Search for any other workflows that might show the proper pattern for using auto
find .github/workflows -type f \( -name "*.yaml" -o -name "*.yml" \) -exec basename {} \;Repository: stephansama/nvim
Length of output: 72
🏁 Script executed:
# Let's check if the auto tool expects GITHUB_TOKEN as an environment variable
# by looking at the package.json scripts and any documentation
cat package.json | jq '.scripts'Repository: stephansama/nvim
Length of output: 523
🏁 Script executed:
# Check if there's a GitHub Actions configuration file or docs about secrets
find . -name ".github" -type d -exec find {} -type f \; | head -20Repository: stephansama/nvim
Length of output: 92
🏁 Script executed:
# Let's verify the specific version of auto being used and its requirements
# Check if there's a lockfile that shows what auto needs
if [ -f pnpm-lock.yaml ]; then
echo "Checking pnpm-lock.yaml for auto configuration..."
head -100 pnpm-lock.yaml
elif [ -f package-lock.json ]; then
echo "Checking package-lock.json..."
grep -A 5 '"auto"' package-lock.json | head -20
elif [ -f yarn.lock ]; then
echo "Checking yarn.lock..."
grep -A 5 "auto@" yarn.lock | head -20
fiRepository: stephansama/nvim
Length of output: 3133
🏁 Script executed:
# Check GitHub's documentation - does auto need explicit token passing?
# Let's look for any CI config or documentation in the repo
find . -maxdepth 2 -name "*.md" -type f -exec grep -l "auto\|release" {} \;Repository: stephansama/nvim
Length of output: 71
🏁 Script executed:
# Check if the package is published to npm (look for publish config in package.json)
cat package.json | jq '.publishConfig, .version' 2>/dev/nullRepository: stephansama/nvim
Length of output: 72
🏁 Script executed:
# Check if there's any GitHub Actions secrets configured in the repo
# Also check for any documentation about the release process
find . -name "*.md" -type f -exec grep -l "npm\|publish\|deploy\|secret" {} \; 2>/dev/null | head -10Repository: stephansama/nvim
Length of output: 71
🏁 Script executed:
# Let's specifically check what auto's shipit command does
# by looking at the auto documentation in devDependencies or checking version
echo "Looking for auto shipit documentation or config..."
grep -r "shipit" . --include="*.md" --include="*.js" --include="*.ts" --include="*.json" 2>/dev/null | grep -v node_modules | head -20Repository: stephansama/nvim
Length of output: 153
🏁 Script executed:
# Let's check GitHub's documentation about GITHUB_TOKEN in Actions
# The key is whether auto can access it automatically or needs it passed explicitly
# Let's look for any GitHub Actions documentation in the repo or check common patterns
# Check if there are any environment variable settings in the workflow
cat .github/workflows/release.yaml | grep -E "env:|GITHUB_TOKEN|secrets"
# Also check if the checkout action fetches with token
cat .github/workflows/release.yaml | grep -A 5 "checkout"Repository: stephansama/nvim
Length of output: 245
🏁 Script executed:
# Check if the project has any CI documentation or examples
find . -maxdepth 2 -name "*.md" -o -name ".git*" -type f 2>/dev/null | xargs grep -l "GITHUB_TOKEN\|GH_TOKEN\|release" 2>/dev/null | head -5Repository: stephansama/nvim
Length of output: 42
🏁 Script executed:
# Check auto CLI documentation to understand what credentials it needs
# Look in the repository for any documentation about setting up releases
ls -la .github/ 2>/dev/null
cat .github/CONTRIBUTING.md 2>/dev/null || cat .github/DEVELOPMENT.md 2>/dev/null || echo "No development docs found"Repository: stephansama/nvim
Length of output: 255
🏁 Script executed:
# Check the auto GitHub Actions documentation/examples
# Look for what environment variables auto expects
# The key question: does auto automatically use the GitHub Actions GITHUB_TOKEN?
# Let's search the actual documentation or examples online by looking at
# what the .autorc expects and what auto needs
# First, let's check if there's any GitHub Actions setup specifically for auto
find . -type f \( -name "*.yml" -o -name "*.yaml" -o -name "*.md" \) -exec grep -l "auto\|GITHUB_TOKEN" {} \; 2>/dev/null
# Also check if the repository is actually using GitHub Actions features that
# would require token passing
cat .github/workflows/release.yaml | head -20Repository: stephansama/nvim
Length of output: 393
🏁 Script executed:
# Key check: In GitHub Actions, GITHUB_TOKEN is available but needs explicit passing
# Let's verify what the auto tool documentation says about authentication
# by checking if there are any examples in the repo or standard patterns
# Check how the checkout action is configured - does it pass a token?
grep -A 3 "uses: actions/checkout" .github/workflows/release.yaml
# Check if there's a permissions section in the job
grep -B 5 "name: Release" .github/workflows/release.yaml | grep -E "permissions|contents"Repository: stephansama/nvim
Length of output: 178
🏁 Script executed:
# Let's get more context - look for any GitHub Actions documentation or examples
# Check what the standard pattern is for using auto in GitHub Actions
# Search for auto-related issues or examples in common places
find . -name "*.md" -o -name "*.txt" | xargs grep -i "auto\|shipit\|release" 2>/dev/null | grep -v node_modules | head -30Repository: stephansama/nvim
Length of output: 454
🏁 Script executed:
# The key question: Can auto access GITHUB_TOKEN automatically in GitHub Actions?
# According to GitHub Actions documentation, GITHUB_TOKEN is available but needs explicit passing
# Let's verify the actual checkout configuration more carefully
cat .github/workflows/release.yamlRepository: stephansama/nvim
Length of output: 978
🏁 Script executed:
# Check if there's a specific section about permissions needed
# Also check what version of checkout is being used
grep -E "permissions:|persist-credentials:|token:" .github/workflows/release.yamlRepository: stephansama/nvim
Length of output: 42
🏁 Script executed:
# Let me verify the core issue: whether auto/shipit needs GITHUB_TOKEN as an env var
# by checking if there are any GitHub Actions best practices documented
# Check the actions/checkout documentation - does persist-credentials=true make GITHUB_TOKEN available?
# According to GitHub Actions docs, GITHUB_TOKEN is NOT automatically available as an env var
# It needs to be explicitly passed with: env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
# Let's verify if the current checkout setup would work with auto
cat .github/workflows/release.yaml | grep -A 2 "Checkout"Repository: stephansama/nvim
Length of output: 151
🏁 Script executed:
# Final verification: Check if auto's documentation or examples show GITHUB_TOKEN requirements
# Look at auto's standard usage patterns - does it need the token as env var?
# According to auto documentation, it needs:
# - GITHUB_TOKEN for GitHub API calls (creating releases, tags, comments)
# - The token should be available as environment variable or passed explicitly
# Let's check if there's any configuration that passes it implicitly
cat .github/workflows/release.yaml | grep -B 5 -A 10 "Run release"Repository: stephansama/nvim
Length of output: 246
Add GITHUB_TOKEN to the release step.
The auto shipit command requires GITHUB_TOKEN to create git tags and GitHub releases. Although this token is available in GitHub Actions, it must be explicitly passed as an environment variable.
Add to the release step:
- name: Run release
run: pnpm run release
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}🤖 Prompt for AI Agents
.github/workflows/release.yaml around lines 39 to 40: the release step runs
`pnpm run release` but does not expose the required GITHUB_TOKEN to the process;
update the step to add an env mapping that sets GITHUB_TOKEN to ${{
secrets.GITHUB_TOKEN }} so the auto shipit/release tooling can create tags and
GitHub releases.
| import { findRoot } from "@manypkg/find-root"; | ||
| import * as fs from "node:fs"; | ||
| import * as fsp from "node:fs/promises"; | ||
| import * as os from "node:os"; | ||
| import * as path from "node:path"; | ||
|
|
||
| const homedir = os.homedir(); | ||
| const { rootDir } = await findRoot(process.cwd()); | ||
|
|
||
| const output = path.join(homedir, "bloat.json"); | ||
| const output = path.resolve(path.join(rootDir, "dist", "bloat.json")); | ||
| const input = path.resolve(path.join(rootDir, "bloat.json")); | ||
|
|
||
| await fsp.mkdir(path.dirname(output), { recursive: true }); |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Add error handling for file system operations.
The findRoot and mkdir operations can fail (e.g., not in a package, permission denied, disk full) but have no error handling. In a CI environment, these failures should produce clear error messages.
🔎 Proposed enhancement
+try {
const { rootDir } = await findRoot(process.cwd());
const output = path.resolve(path.join(rootDir, "dist", "bloat.json"));
const input = path.resolve(path.join(rootDir, "bloat.json"));
await fsp.mkdir(path.dirname(output), { recursive: true });
+} catch (error) {
+ console.error("Failed to initialize paths:", error.message);
+ process.exit(1);
+}🤖 Prompt for AI Agents
In lua/plugins/debug/bloat.js around lines 3 to 13, the top-level await calls to
findRoot and the mkdir call lack error handling; wrap the asynchronous
operations in try/catch blocks (or a single enclosing try/catch) to catch errors
from findRoot and fsp.mkdir, log a clear, contextual error message to stderr
including the caught error details, and exit the process with a non-zero code
(e.g., process.exit(1)) so CI fails visibly; ensure any path resolution still
occurs inside the try and that the error messages identify the failing operation
(findRoot or mkdir) and the path involved.
| generate-bloat: | ||
| nvim --version | head -n 1 | ||
| nvim --headless -u ./init.lua \ | ||
| +"Bloat bloat.json" \ | ||
| +qa |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# First, locate and read .autorc to see the asset path
if [ -f ".autorc" ]; then
echo "=== .autorc content ==="
cat .autorc
else
echo ".autorc not found in root"
fiRepository: stephansama/nvim
Length of output: 325
🏁 Script executed:
#!/bin/bash
# Search for bloat.json references in the codebase
echo "=== Files mentioning bloat.json ==="
rg "bloat\.json" --type-list | head -5
rg "bloat\.json" -lRepository: stephansama/nvim
Length of output: 538
🏁 Script executed:
#!/bin/bash
# Check if bloat.js exists and examine it
if [ -f "lua/plugins/debug/bloat.js" ]; then
echo "=== lua/plugins/debug/bloat.js ==="
cat lua/plugins/debug/bloat.js
else
echo "bloat.js not found at lua/plugins/debug/bloat.js"
# Search for it
fd "bloat" --type f
fiRepository: stephansama/nvim
Length of output: 1052
🏁 Script executed:
#!/bin/bash
# Check init.lua for Bloat command configuration
echo "=== Searching for Bloat command in Lua files ==="
rg "Bloat" --type lua -B 2 -A 2Repository: stephansama/nvim
Length of output: 271
🏁 Script executed:
#!/bin/bash
# Check if there are other Makefile targets or if bloat.js is called elsewhere
echo "=== Full Makefile content ==="
cat Makefile
echo -e "\n=== Search for bloat.js execution ==="
rg "bloat\.js" --type sh --type makefile --type bashRepository: stephansama/nvim
Length of output: 964
🏁 Script executed:
#!/bin/bash
# Check if there's a release workflow or script that calls bloat.js
echo "=== Check for CI/release workflows ==="
fd "workflow|release|build" --type f -d 3
ls -la .github/workflows/ 2>/dev/null || echo "No .github/workflows found"Repository: stephansama/nvim
Length of output: 290
🏁 Script executed:
#!/bin/bash
# Check the release workflow
echo "=== .github/workflows/release.yaml ==="
cat .github/workflows/release.yamlRepository: stephansama/nvim
Length of output: 1017
🏁 Script executed:
#!/bin/bash
# Search for any pnpm script that might call bloat.js
echo "=== Checking package.json for bloat-related scripts ==="
cat package.json | jq '.scripts' 2>/dev/null || grep -A 20 '"scripts"' package.json 2>/dev/null | head -50Repository: stephansama/nvim
Length of output: 579
The release workflow must run the bloat.json transformation step before asset upload.
The make generate-bloat target generates bloat.json in the repository root via the bloat.nvim plugin, but the release workflow never invokes pnpm run build:bloat, which reads the root file and writes the transformed version to ./dist/bloat.json as expected by .autorc.
Without this step, the asset upload in .autorc will fail because ./dist/bloat.json does not exist. Either add pnpm run build:bloat to the release workflow after make generate-bloat, or add it as a step within the Makefile's generate-bloat target.
🤖 Prompt for AI Agents
In Makefile around lines 6 to 10, the generate-bloat target creates bloat.json
in repo root but does not run the transformation that writes ./dist/bloat.json
required by the release asset upload; update the target to run the
transformation (execute `pnpm run build:bloat`) after the nvim invocation so the
transformed file is produced in ./dist, or alternatively add a step to the
release workflow immediately after calling `make generate-bloat` to run `pnpm
run build:bloat`; ensure the command runs in the repository root and fails the
target/workflow if the build step exits non‑zero.
| "plugins": [ | ||
| "prettier-plugin-organize-imports", | ||
| "prettier-plugin-sort-package-json", | ||
| "prettier-plugin-packagejson", | ||
| "@prettier/plugin-lua" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
prettier-plugin-sort-package-json vs prettier-plugin-packagejson differences
💡 Result:
Short comparison — prettier-plugin-sort-package-json vs prettier-plugin-packagejson
-
Purpose
- prettier-plugin-packagejson: well-established plugin that formats/sorts package.json using the sort-package-json rules (opinionated, known key order plus alphabetical fallback). [1][2]
- prettier-plugin-sort-package-json: a smaller plugin whose goal is to sort package.json in a consistent/zero-config way (alphanumeric/consistent ordering). [3]
-
Sorting behavior
- packagejson: uses the sort-package-json ordering (a curated top-level key order modeled on common projects and then alphabetical for unknown keys). Also sorts scripts/deps, etc. [2]
- sort-package-json: focuses on consistent sorting (zero-configuration, auto-fix with Prettier); exact order may be simpler/alphabetical or plugin-specific. [3]
-
Configuration & opinionation
- packagejson: opinionated (uses sort-package-json defaults); intended to produce a specific “nice” order. Less emphasis on runtime config beyond Prettier plugins. [2]
- sort-package-json: advertises zero-config and “set-and-forget” sorting; fewer opinionated key-order choices. [3]
-
Maintenance & popularity
- packagejson: widely used and actively published (many dependents, frequent releases). Sources show many downloads and versions on npm/GitHub. [1][2]
- sort-package-json: smaller project with fewer releases/usage (less active/popular in ecosystem). Check its registry page for latest status. [3]
-
Implementation notes
- packagejson depends on the sort-package-json library under the hood and integrates with Prettier’s package.json handling. [2]
- sort-package-json is a Prettier plugin that hooks into Prettier to sort package.json automatically; implementation and options are minimal/zero-dependency. [3]
If you want a specific recommendation: use prettier-plugin-packagejson for a well-tested, opinionated ordering (widely adopted). Use prettier-plugin-sort-package-json if you prefer a minimal, zero-config sorter — but check the package’s repo/activity before adopting.
Sources:
[1] prettier-plugin-packagejson (package files / unpkg / npm metadata).
[2] prettier-plugin-packagejson npm/jsDelivr documentation (describes use of sort-package-json and key order).
[3] prettier-plugin-sort-package-json registry entry / npm.io (package description and usage).
These plugins have different sorting behaviors — verify the output format change is acceptable.
The replacement from prettier-plugin-sort-package-json to prettier-plugin-packagejson is not a straightforward swap. prettier-plugin-packagejson is more opinionated (using curated key ordering plus alphabetical fallback), while prettier-plugin-sort-package-json uses simpler, zero-config sorting. Though both sort package.json, they will produce different formatting. Verify that the output with prettier-plugin-packagejson matches the project's expectations, and be aware that this change will reformat package.json differently than before.
🤖 Prompt for AI Agents
In package.json around lines 32 to 35, the new plugin
"prettier-plugin-packagejson" has different sorting behavior than the previous
"prettier-plugin-sort-package-json"; run Prettier locally (or CI) with the new
plugin, compare the resulting package.json diff to the previous output, and
confirm the new ordering is acceptable. If differences are not acceptable,
either revert to the previous plugin, pin the plugin version that matches
expected behavior, or add/configure a plugin (or an .prettierrc override) to
reproduce the original key ordering; update README/CONTRIBUTING to note the
chosen behavior and ensure CI formatting checks reflect the final decision.
| "eslint --fix" | ||
| ] | ||
| } | ||
| "packageManager": "[email protected]" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
latest stable version of pnpm December 2025
💡 Result:
The latest stable pnpm version is 10.26.2 — released December 23, 2025. [1][2]
Sources:
[1] endoflife.date — pnpm (shows 10.26.2 as latest, 23 Dec 2025).
[2] pnpm release notes / changelog (v10.26.2).
Update pnpm to the latest stable version (10.26.2).
The packageManager field is good for reproducibility, but pnpm 10.13.1 is outdated. Update to the current stable version 10.26.2 (released December 23, 2025) to ensure you have the latest fixes, performance improvements, and security updates.
🤖 Prompt for AI Agents
In package.json around line 76, the packageManager field currently pins
[email protected] and should be updated to the latest stable 10.26.2; edit that line
to "packageManager": "[email protected]" and then run your package manager (e.g.,
pnpm install) to refresh the lockfile and ensure the updated pnpm metadata is
applied.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
Makefile (1)
6-11: The transformation step is still missing from the target.As flagged in the previous review, the
generate-bloattarget createsbloat.jsonin the repository root but does not runpnpm run build:bloatto transform it into./dist/bloat.json. Without this step, the release workflow's asset upload configured in.autorcwill fail because./dist/bloat.jsondoes not exist.🔎 Proposed fix to add the transformation step
generate-bloat: nvim --version | head -n 1 XDG_CONFIG_HOME=$PWD \ nvim --headless \ +"Bloat bloat.json" \ +qa + $(MISE) pnpm run build:bloat
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
Makefile
| generate-bloat: | ||
| nvim --version | head -n 1 | ||
| XDG_CONFIG_HOME=$PWD \ | ||
| nvim --headless \ | ||
| +"Bloat bloat.json" \ | ||
| +qa |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider adding error handling for the Neovim command.
The target doesn't verify whether the headless Neovim command succeeds or whether bloat.json is actually created. If the Bloat plugin fails or the command errors, the Makefile will continue silently.
🔎 Proposed improvement with validation
generate-bloat:
nvim --version | head -n 1
XDG_CONFIG_HOME=$PWD \
nvim --headless \
+"Bloat bloat.json" \
+qa
+ @test -f bloat.json || (echo "Error: bloat.json was not generated" && exit 1)
$(MISE) pnpm run build:bloat🤖 Prompt for AI Agents
In Makefile around lines 6 to 11, the generate-bloat target runs headless Neovim
but doesn’t check the command’s exit status or verify that bloat.json was
produced; update the recipe to fail the build on error by checking nvim’s exit
code and then asserting bloat.json exists (e.g., run the nvim command and if it
returns non-zero print an error and exit 1, then test -f bloat.json and if
missing print an error and exit 1).
No description provided.