Added Dependencies section describing third-party and pi package dependencies.
EditClarified normal dependencies versus built-in pi packages.
EditRan npm check via commit hook.
VerifyCommitted and pushed documentation changes.
Cleanup@packages/coding-agent/docs/packages.md should also describe how to include 3rd party dependencies (simply via package.json) that they automatically get installed along with shit, but that for pi dependencies, you need to make them peer dependencies with * (i think we already say that?)
Preparing to read full file for doc update
Planning doc addition for third-party dependencies
I'm preparing to add documentation about handling third-party and peer dependencies in Pi packages, clarifying automatic installs via package.json for npm and git packages, and emphasizing peer deps with wildcard for Pi dependencies; next, I'll search existing docs to find an appropriate placement and avoid duplication.
>rg -n "peer" packages/coding-agent/docs/packages.mdPlanning dependency section addition
I'm preparing to add a "Dependencies" subsection explaining how third-party dependencies are declared and installed, clarifying dependencies vs. optional dependencies for npm and git packages, and noting peerDependencies usage to avoid duplication; deciding the best place to insert it is after "Creating a Pi Package" or "Package Structure."
Drafting dependency section text
I'm composing a new "Dependencies" section to add after "Package Structure," outlining how third-party runtime dependencies go in dependencies and install automatically via npm during pi package installs, while pi package dependencies should be declared as peerDependencies with "*" to let the host project dedupe and manage versions, noting bundledDependencies as an alternative for shipping pi packages internally.
Adding Dependencies section after Bundling
I'm inserting a new Dependencies section right after the Bundling Other Pi Packages part, just after the paragraph about the pi-package-test. This explains how third-party dependencies go in package.json, how Pi installs them automatically, and how Pi packages should declare peerDependencies to allow version control and deduplication.
Refining Dependencies wording
I'm clarifying the Dependencies section to specify using bundledDependencies for shipping Pi packages inside a tarball and referencing "Bundling Other Pi Packages" explicitly; also opting for "third party" without a hyphen and emphasizing that dependencies are installed along with the package.
Summarizing documentation update
Updated wording for hyphen usage in peerDependencies explanation and confirmed consistent phrasing; no tests run since itās a doc change.
Summary:
Tests not run (documentation change).
dude, did you read all of @packages/coding-agent/docs/packages.md i was talking about the "built-in" pi packages, pi-ai, pi-agent-core, pi-coding-agent, pi-tui, typebox
Reviewing file for dependency update
I'm rereading the full file to locate the best place to add details about built-in pi packages dependencies before proceeding with the update.
Planning Dependencies section update
I'm preparing to expand the Dependencies section to clarify built-in pi packages require peer dependencies with wildcard versions and to explain how third-party dependencies are handled differently via package.json. Next, I'll confirm actual package names by inspecting the repo.
>rg -n "pi-ai|pi-agent-core|pi-coding-agent|pi-tui|typebox" packagesIdentifying built-in package naming for docs
The built-in packages use scoped npm names like @mariozechner/pi-ai and @sinclair/typebox; these should be documented as built-ins, distinguishing them from third-party dependencies. Next, I'll update the Dependencies section in the coding-agent docs to clarify these points and the bundled dependencies for extensions.
>rg -n "pi-ai|pi-agent-core|pi-coding-agent|pi-tui|typebox" packages/coding-agent/docsUpdating dependencies doc with built-ins guidance
I'm adding a paragraph clarifying that core pi packages like pi-ai, pi-agent-core, pi-coding-agent, pi-tui, and @sinclair/typebox are bundled and available at runtime, so extensions should list them as peerDependencies with "*" to avoid duplicates, while all other packages go in dependencies. I'll also adjust the existing Dependencies section and consider including a concise example and explicit bullet list.
Revising Dependencies section text
I'm rewriting the Dependencies section to clearly state that core pi packages used by extensions are bundled and must be listed as peerDependencies with "*", excluding them from dependencies and bundledDependencies; other pi packages should also be peerDependencies for separate installation, while third-party dependencies go in dependencies installed automatically with the package. I'll keep the style clean with sentences and avoid em dashes as requested.
Summary:
Tests not run (documentation change).
+132 Other pi packages should also be peerDependencies with a "*" range so users install them
separately via settings or pi install, which keeps a single copy. Use bundledDependencies only if you
want to ship a pi package inside your tarball.
no, pi packages depending on other pi packages must bundle, otherwise we get into devil's kitchen. the modules are loaded separately from each other and can't collide
Confirming full file reread before editing
The file was previously read fully before the first edit, but since it changed after that, I'll reread the complete, updated file before applying the new doc adjustment.
Planning doc update to clarify pi package dependencies
I'll update the doc to say pi packages depending on other pi packages must list those as dependencies and in bundledDependencies to ensure bundling, replacing the prior peerDependency guidance for these cases, while keeping built-in packages as peerDependencies with "*". This clarifies the separate loading environment and bundling requirement.
Revising pi package bundling guidance
I'm updating the paragraph to clarify that other pi packages must be bundled by adding them to dependencies and bundledDependencies and referencing via node_modules paths, emphasizing isolated module roots prevent sharing. I'll avoid em dashes and structure as straightforward sentences.
Summary:
Tests not run (documentation change).
do we state the other pi packages shit twice now? read the ful lfile
Identifying redundant sections
The file has two sections covering bundling other pi packages, which appear redundant but not exact duplicates. Should I propose removing one and consolidating them?
Yes. It is covered in two places: the āBundling Other Pi Packagesā section under Package Structure and the Dependencies section. Do you want me to consolidate into one section and remove the other?
consolidate
Planning doc consolidation and hyphen cleanup
I'm preparing to remove the "Bundling Other Pi Packages" section and move its example into the Dependencies section, consolidating guidance while avoiding introducing spaced hyphens as sentence interrupters.
Detailing exact doc edits for consolidation
I'm preparing precise edits to remove the entire "Bundling Other Pi Packages" section and insert its JSON example plus bundling instructions into the Dependencies section, ensuring no spaced hyphens or em dashes appear and maintaining proper spacing to avoid double blank lines.
Summary:
Tests not run (documentation change).
commit and push
Committing and pushing changes
I'll check the git status, add the specific file, commit with a clear message, and push the changes.
>git status --short>git add packages/coding-agent/docs/packages.md>git commit -m "docs(coding-agent): clarify pi package dependency bundling"Pushing committed changes
>git pushSummary:
Tests: npm run check (triggered by commit hook).
what about plain old dependencies?
Answering about plain dependencies
Third-party dependencies go in dependencies and install with npm install. For pi built-ins, peerDependencies are set to "*". Other pi packages require bundling. I can update the docs if needed.
Plain third party deps go in dependencies. Pi runs npm install on install, so they are installed automatically. The special cases are the built-in pi packages as peerDependencies with "*" and other pi packages bundled. If you want this called out more explicitly in the doc, say where.
in the same section you just consolidated. "normal dependencies that themselves don't register extensions, skills, prompt tempaltes, or themes go into the regular "dependencies""
Editing Dependencies section wording
Adding a clear, simple sentence to the first paragraph in the Dependencies section to specify that dependencies not registering extensions, skills, prompt templates, or themes belong in dependencies; avoiding em dashes and quotes per instructions.
Summary:
Tests not run (documentation change).
commit and push
>git status --short>git add packages/coding-agent/docs/packages.md>git commit -m "docs(coding-agent): clarify dependency categories">git pushSummary:
Tests: npm run check (commit hook).