chore: repo hygiene — gitignore argent init artifacts + resync package-lock for npm 11#383
Merged
Merged
Conversation
… `argent init` Running `argent init` inside the repo writes MCP/skill config for the newer agent harnesses (.agents/, .codex/, .gemini/, .opencode/, opencode.json) plus a skills-lock.json. None were ignored, so they showed up as untracked clutter on every branch (including main) and could be committed by accident. These are the same class of generated artifact as the already-ignored .claude/, .cursor/, .vscode/, .mcp.json entries — just the newer harnesses. skills-lock.json is especially unsafe to commit: it bakes in machine-specific absolute skill paths (e.g. /Users/<name>/.nvm/.../@swmansion/argent/skills). None of these paths were ever tracked, so ignoring them removes no history.
The committed lockfile carried 26 `"peer": true` and 1 `"dev": true` markers written by an older npm. CI's lockfile-sync job runs under Node 24 (npm 11), which no longer emits those markers, so `npm install --package-lock-only` produced a 27-line diff and the "package-lock.json in sync" check failed on every PR — pre-existing drift on main, unrelated to the .gitignore change. Regenerated with Node 24 / npm 11.12.1: 27 deletions, no version/resolved/ integrity changes (pure metadata normalization). Matches what CI expects.
filip131311
changed the title
argent initargent init artifacts + resync package-lock for npm 11
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two related repo-hygiene fixes surfaced while triaging a "lock files problem on main".
1.
package-lock.jsonout of sync (fixes the failing CI check)The
lockfile.ymljob (package-lock.json in sync) was failing on every PR, including this one — but it's pre-existing drift onmain, not caused by the.gitignorechange.Root cause: the committed lockfile carried 26×
"peer": true,and 1×"dev": true,markers written by an older npm. CI pins Node 24 (npm 11), which no longer emits those markers, sonpm install --package-lock-onlyproduced a 27-line diff and the check failed. (Locally under Node 22 / npm 10 the markers are preserved, so the drift was invisible there — which is why the first pass looked green.)Fix: regenerated with Node 24 / npm 11.12.1 → 27 deletions, no version/resolved/integrity changes (pure metadata normalization). Matches exactly what CI expects.
2. gitignore
argent initagent-harness artifactsRunning
argent initinside the repo writes generated config into the repo root that was never ignored:.agents/,.codex/config.toml,.gemini/,.opencode/,opencode.jsonskills-lock.jsonThese appeared as untracked clutter on every branch and could be committed by accident.
skills-lock.jsonis the worst offender — it bakes in machine-specific absolute paths (/Users/<name>/.nvm/.../@swmansion/argent/skills). These are the same class of artifact as the already-ignored.claude/,.cursor/,.vscode/,.mcp.json, just the newer harnesses.git log --allconfirms none were ever tracked, so nothing is removed from history.