fix(exports): add default export conditions for Node/tsx resolution - #1614
Conversation
Import-only package export maps caused ERR_PACKAGE_PATH_NOT_EXPORTED when loading SDK packages via Node or tsx. Add default conditions across packages so standard Node tooling can resolve the same entrypoints Bun already uses. Fixes #1613 Co-authored-by: Cursor <cursoragent@cursor.com>
|
The latest Agentuity deployment details.
View deployment logs with the Agentuity CLI: |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (23)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (20)
📜 Recent review details⏰ Context from checks skipped due to timeout. (15)
🧰 Additional context used🧠 Learnings (1)📚 Learning: 2026-03-27T23:18:58.450ZApplied to files:
🔇 Additional comments (2)
📝 WalkthroughWalkthroughThis PR adds explicit ChangesPackage exports default condition additions
Sequence Diagram(s)No sequence diagram generated; the changes are static package metadata updates. Estimated Code Review Effort: 2/5 Related Issues: None specified. Related PRs: None specified. Suggested Labels: dependencies, configuration Suggested Reviewers: None specified. 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
Comment |
📦 Canary Packages Publishedversion: PackagesInstallAdd to your {
"dependencies": {
"@agentuity/claude-code": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-claude-code-3.1.7-e43b730.tgz",
"@agentuity/runtime": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-runtime-3.1.7-e43b730.tgz",
"@agentuity/task": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-task-3.1.7-e43b730.tgz",
"@agentuity/cli": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-cli-3.1.7-e43b730.tgz",
"@agentuity/sandbox": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-sandbox-3.1.7-e43b730.tgz",
"@agentuity/migrate": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-migrate-3.1.7-e43b730.tgz",
"@agentuity/coder-tui": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-coder-tui-3.1.7-e43b730.tgz",
"@agentuity/keyvalue": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-keyvalue-3.1.7-e43b730.tgz",
"@agentuity/telemetry": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-telemetry-3.1.7-e43b730.tgz",
"@agentuity/webhook": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-webhook-3.1.7-e43b730.tgz",
"@agentuity/api": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-api-3.1.7-e43b730.tgz",
"@agentuity/analytics": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-analytics-3.1.7-e43b730.tgz",
"create-agentuity": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/create-agentuity-3.1.7-e43b730.tgz",
"@agentuity/aigateway": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-aigateway-3.1.7-e43b730.tgz",
"@agentuity/drizzle": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-drizzle-3.1.7-e43b730.tgz",
"@agentuity/core": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-core-3.1.7-e43b730.tgz",
"@agentuity/server": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-server-3.1.7-e43b730.tgz",
"@agentuity/hono": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-hono-3.1.7-e43b730.tgz",
"@agentuity/postgres": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-postgres-3.1.7-e43b730.tgz",
"@agentuity/skills": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-skills-3.1.7-e43b730.tgz",
"@agentuity/storage": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-storage-3.1.7-e43b730.tgz",
"@agentuity/opencode": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-opencode-3.1.7-e43b730.tgz",
"@agentuity/pi": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-pi-3.1.7-e43b730.tgz",
"@agentuity/config": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-config-3.1.7-e43b730.tgz",
"@agentuity/stream": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-stream-3.1.7-e43b730.tgz",
"@agentuity/email": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-email-3.1.7-e43b730.tgz",
"@agentuity/queue": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-queue-3.1.7-e43b730.tgz",
"@agentuity/schedule": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-schedule-3.1.7-e43b730.tgz",
"@agentuity/coder": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-coder-3.1.7-e43b730.tgz",
"@agentuity/vector": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-vector-3.1.7-e43b730.tgz",
"@agentuity/db": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-db-3.1.7-e43b730.tgz",
"@agentuity/adapter": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-adapter-3.1.7-e43b730.tgz",
"@agentuity/genesis": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-genesis-3.1.7-e43b730.tgz",
"@agentuity/vite": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-vite-3.1.7-e43b730.tgz",
"@agentuity/client": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-client-3.1.7-e43b730.tgz",
"@agentuity/schema": "https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-schema-3.1.7-e43b730.tgz"
}
}Or install directly: bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-claude-code-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-runtime-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-task-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-cli-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-sandbox-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-migrate-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-coder-tui-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-keyvalue-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-telemetry-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-webhook-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-api-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-analytics-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/create-agentuity-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-aigateway-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-drizzle-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-core-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-server-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-hono-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-postgres-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-skills-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-storage-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-opencode-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-pi-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-config-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-stream-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-email-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-queue-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-schedule-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-coder-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-vector-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-db-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-adapter-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-genesis-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-vite-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-client-3.1.7-e43b730.tgz
bun add https://agentuity-sdk-objects.t3.storageapi.dev/npm/3.1.7-e43b730/agentuity-schema-3.1.7-e43b730.tgz |
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Nitpick comments (12)
packages/db/package.json (1)
16-20: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winMove
"types"before"import"/"default"in the conditions object.TypeScript's own module resolution docs require the
typescondition to appear first in an exports conditions block; since resolution matches the first satisfying key, listingimportbeforetypesrisks TypeScript picking up the wrong entry when it also treatsimportas a matching condition.packages/genesis/package.jsonandpackages/storage/package.jsonalready ordertypesfirst — worth aligning here too for consistency and correctness.The "types" condition should always come first in "exports".♻️ Proposed fix
"exports": { ".": { - "import": "./dist/index.js", "types": "./dist/index.d.ts", + "import": "./dist/index.js", "default": "./dist/index.js" } },🤖 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 `@packages/db/package.json` around lines 16 - 20, The exports conditions object in the package.json entry currently lists import/default before types, which can cause TypeScript to resolve the wrong target. Update the exports block for the "." subpath so the types condition is the first key, matching the ordering used in packages/genesis/package.json and packages/storage/package.json, while keeping the existing import and default entries unchanged.packages/email/package.json (1)
16-20: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winSame
types-ordering issue as other single-entry packages.Same concern as
packages/db/package.json:typesshould be listed beforeimport/defaultper The "types" condition should always come first in "exports".Dependencies (
@agentuity/adapter,@agentuity/client,@agentuity/config, no direct@agentuity/core) remain compliant with the guideline for this package. As per coding guidelines,packages/email/**/package.json: Maintain dependencies on@agentuity/adapter,@agentuity/client, and@agentuity/configwithout a direct@agentuity/coredependency.🤖 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 `@packages/email/package.json` around lines 16 - 20, The exports map in packages/email/package.json has the same condition-order issue as other single-entry packages: the "types" condition must come first. Update the "." export entry so the existing fields in that object are reordered to place "types" before "import" and "default", keeping the rest of the package metadata and dependency compliance unchanged.Source: Coding guidelines
packages/analytics/package.json (1)
11-20: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winSame
types-ordering issue on both"."and"./beacon".Both subpaths list
importbeforetypes, which contradicts the TypeScript recommendation thattypesmust be first (The "types" condition should always come first in "exports".). Since this package has multiple subpaths, this affects both entries.🤖 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 `@packages/analytics/package.json` around lines 11 - 20, The exports map in package.json has the same condition-order problem for both the "." and "./beacon" subpaths: the types condition is not listed first. Update the exports entries so that types comes before import and default in each subpath, preserving the existing targets while reordering the conditions to match the TypeScript requirement.packages/keyvalue/package.json (1)
16-20: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winSame
types-ordering issue.Same recurring concern as sibling packages —
importshould not precedetypes(The "types" condition should always come first in "exports".).Dependencies on
@agentuity/adapter,@agentuity/client,@agentuity/config, andzodare present and compliant. As per coding guidelines,packages/keyvalue/**/package.json: Declare dependencies on@agentuity/adapter,@agentuity/client,@agentuity/config, and zod in package.json.🤖 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 `@packages/keyvalue/package.json` around lines 16 - 20, The package export map in the keyvalue package has the conditions in the wrong order: `import` is listed before `types` in the `"."` export entry. Update the `exports` block in the package.json so `types` comes first, then `import`, then `default`, matching the convention used by the sibling packages and keeping the `types` condition first in `exports`.Source: Coding guidelines
packages/migrate/package.json (1)
20-24: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winSame
types-ordering issue.Same recurring concern —
importprecedestypesin the exports conditions block (The "types" condition should always come first in "exports".).🤖 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 `@packages/migrate/package.json` around lines 20 - 24, The exports conditions block in the package config has the same ordering issue: the "types" condition must come before "import" in the "." export entry. Update the export map in the package.json for the migrate package so the condition order matches the expected convention, keeping the existing targets for import, types, and default unchanged.packages/hono/package.json (1)
10-14: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winSame
types-ordering issue.Same recurring concern:
importprecedestypesin the conditions object, which deviates from the TypeScript-recommended ordering (The "types" condition should always come first in "exports".).🤖 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 `@packages/hono/package.json` around lines 10 - 14, The exports conditions object has the wrong condition ordering because import is listed before types. Update the package.json exports entry for the "." subpath so types is the first condition, followed by import and default, matching the TypeScript-recommended order in the exports map.packages/runtime/package.json (1)
11-15: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winSame
"types"/"import"ordering concern aspackages/pi/package.json.
"import"precedes"types"in this exports block, which can cause incorrect type resolution undernode16/nodenextmodule resolution. Consider reordering to puttypesfirst.🤖 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 `@packages/runtime/package.json` around lines 11 - 15, The exports map in the package manifest has "import" before "types", which can lead to incorrect type resolution under node16/nodenext. Update the package.json exports entry for "." so that the "types" condition is listed before "import" and keep "default" unchanged; use the existing exports block in packages/runtime/package.json as the target for the reorder.packages/pi/package.json (1)
16-20: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winConsider ordering
"types"before"import"/"default"in the exports map.
defaultcorrectly comes last as a fallback. However,"types"still comes after"import"(pre-existing, not introduced here). Under TypeScript'snode16/nodenextresolution, exports conditions are matched in object-declaration order, so if"import"is listed before"types", type resolution can pick theimportstring entry instead of the.d.tsfile. Since this PR already touches this exact block, it's a good opportunity to fix the ordering too (comparepackages/schema/package.json, which already liststypesfirst).💡 Suggested reorder
".": { - "import": "./dist/index.js", "types": "./dist/index.d.ts", + "import": "./dist/index.js", "default": "./dist/index.js" }🤖 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 `@packages/pi/package.json` around lines 16 - 20, The exports map in the package.json block for the "." entry has the TypeScript types condition ordered after "import", which can interfere with node16/nodenext resolution. Reorder the conditions in this entry so "types" comes first and keep "default" last, matching the pattern already used in packages/schema/package.json and preserving the existing paths for the package export.packages/schedule/package.json (1)
16-20: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winSame
"types"/"import"ordering concern aspackages/pi/package.json.
"import"precedes"types"here as well; consider reordering to matchpackages/schema/package.json.🤖 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 `@packages/schedule/package.json` around lines 16 - 20, The package export map in the schedule package has the same key ordering issue as the other package configs: the subpath export under the main "." entry lists "import" before "types". Reorder the keys in the package.json export definition for the "." entry so it matches the convention used in packages/schema/package.json, keeping the same values but placing "types" before "import".packages/sandbox/package.json (1)
16-20: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winSame
"types"/"import"ordering concern aspackages/pi/package.json.
"import"precedes"types"here; consider reordering (seepackages/schema/package.jsonfor the correct pattern).🤖 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 `@packages/sandbox/package.json` around lines 16 - 20, The package export map in the root "." entry has the same key ordering issue as the other package manifest: reorder the conditions so "types" comes before "import" in the exports object, matching the pattern used in the referenced package.json files. Update the export entry in the package manifest accordingly without changing the values.packages/server/package.json (1)
16-20: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winSame
"types"/"import"ordering concern aspackages/pi/package.json.
"import"precedes"types"here; consider reordering to matchpackages/schema/package.json.🤖 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 `@packages/server/package.json` around lines 16 - 20, The package export map in the server package has the same ordering issue as the other package.json files: the export entry under the "." key places "import" before "types". Update the exports object in packages/server/package.json so the "types" field comes before "import", matching the ordering used in packages/schema/package.json and the other package manifests.packages/queue/package.json (1)
16-20: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winSame
"types"/"import"ordering concern aspackages/pi/package.json.
"import"precedes"types"here too; under TSnode16/nodenextresolution this can cause type declarations to resolve incorrectly since condition matching is order-dependent on the object's key order. Consider movingtypesfirst, as inpackages/schema/package.json.🤖 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 `@packages/queue/package.json` around lines 16 - 20, The package exports map in the queue package has the same condition-order issue as the pi package: the `exports["."]` object currently lists `import` before `types`, which can affect TypeScript `node16`/`nodenext` resolution. Update the `exports` entry in `package.json` so `types` is listed before `import` (matching the pattern used in `schema`), while keeping the same targets for `./dist/index.d.ts` and `./dist/index.js`.
🤖 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 `@packages/aigateway/package.json`:
- Around line 16-20: The export map for the package root currently lists the
conditional entries in the wrong order. Update the package.json exports object
for the "." entry so that the types condition comes before import, keeping the
existing values for index.js and index.d.ts unchanged. Use the export map entry
under the root export key to make the ordering fix.
In `@packages/cli/package.json`:
- Around line 13-17: The package exports for the cli entrypoint are ordered
incorrectly, which can cause TypeScript resolution to bypass the declaration
file. Update the conditional exports in the package.json entry for the root
export so that the types condition in the main export object is listed before
import, keeping the existing paths and default entry unchanged. Use the export
map under the "." key as the place to make this ordering fix.
In `@packages/coder-tui/package.json`:
- Around line 16-20: The export condition order in the package.json exports map
for the coder-tui package is incorrect, causing TypeScript to prefer the JS
entrypoint over the declaration file in node16/nodenext/bundler resolution.
Update the "." export entry so the types condition comes before import, while
keeping the same targets for the exports object.
In `@packages/coder/package.json`:
- Around line 16-20: Reorder the conditional exports entry in the package.json
exports map for the root export so the types condition is listed before import
in the main package export object. Update the "." export block accordingly,
keeping the existing paths the same, so TypeScript can resolve ./dist/index.d.ts
before selecting the runtime module from import/default.
In `@packages/create-agentuity/package.json`:
- Around line 11-15: The package.json exports entry for the root subpath should
list the TypeScript declaration target first so resolution prefers types before
JavaScript. Update the `exports` object for the `.` key by reordering the
existing `types`, `import`, and `default` fields so `types` comes before
`import`, keeping the same paths and values.
In `@packages/stream/package.json`:
- Around line 16-20: Reorder the conditional exports in the package.json exports
map for the stream package so the types condition is listed before import in the
"." entry. Update the export object in the package’s package.json to place the
types field ahead of import (and keep default after), since the TypeScript
resolver used by node16/nodenext/bundler reads conditions in order and the
current ordering in the package exports can cause it to miss the declaration
file.
In `@packages/task/package.json`:
- Around line 16-20: The export map for the package root currently lists the
conditions in an order that can cause TypeScript resolution to pick the JS entry
before declarations; update the package.json export object for "." so the
"types" condition is listed before "import" in the same export map, keeping the
existing values intact and preserving the "default" entry.
In `@packages/telemetry/package.json`:
- Around line 10-14: The exports entry in packages/telemetry/package.json needs
the TypeScript declaration path prioritized before the runtime import path so
node16/nodenext/bundler resolution can find the types reliably. Update the "."
export object to place the types field ahead of import in the same export block,
keeping the existing values for ./dist/index.d.ts and ./dist/index.js unchanged.
In `@packages/vector/package.json`:
- Around line 16-20: The exports entry for the package root in package.json has
the conditions ordered incorrectly, so TypeScript may not pick up the
declaration file. Update the root export object under the "." key in the exports
map so that the types condition is listed before import, while keeping the
existing dist paths and default export intact.
---
Nitpick comments:
In `@packages/analytics/package.json`:
- Around line 11-20: The exports map in package.json has the same
condition-order problem for both the "." and "./beacon" subpaths: the types
condition is not listed first. Update the exports entries so that types comes
before import and default in each subpath, preserving the existing targets while
reordering the conditions to match the TypeScript requirement.
In `@packages/db/package.json`:
- Around line 16-20: The exports conditions object in the package.json entry
currently lists import/default before types, which can cause TypeScript to
resolve the wrong target. Update the exports block for the "." subpath so the
types condition is the first key, matching the ordering used in
packages/genesis/package.json and packages/storage/package.json, while keeping
the existing import and default entries unchanged.
In `@packages/email/package.json`:
- Around line 16-20: The exports map in packages/email/package.json has the same
condition-order issue as other single-entry packages: the "types" condition must
come first. Update the "." export entry so the existing fields in that object
are reordered to place "types" before "import" and "default", keeping the rest
of the package metadata and dependency compliance unchanged.
In `@packages/hono/package.json`:
- Around line 10-14: The exports conditions object has the wrong condition
ordering because import is listed before types. Update the package.json exports
entry for the "." subpath so types is the first condition, followed by import
and default, matching the TypeScript-recommended order in the exports map.
In `@packages/keyvalue/package.json`:
- Around line 16-20: The package export map in the keyvalue package has the
conditions in the wrong order: `import` is listed before `types` in the `"."`
export entry. Update the `exports` block in the package.json so `types` comes
first, then `import`, then `default`, matching the convention used by the
sibling packages and keeping the `types` condition first in `exports`.
In `@packages/migrate/package.json`:
- Around line 20-24: The exports conditions block in the package config has the
same ordering issue: the "types" condition must come before "import" in the "."
export entry. Update the export map in the package.json for the migrate package
so the condition order matches the expected convention, keeping the existing
targets for import, types, and default unchanged.
In `@packages/pi/package.json`:
- Around line 16-20: The exports map in the package.json block for the "." entry
has the TypeScript types condition ordered after "import", which can interfere
with node16/nodenext resolution. Reorder the conditions in this entry so "types"
comes first and keep "default" last, matching the pattern already used in
packages/schema/package.json and preserving the existing paths for the package
export.
In `@packages/queue/package.json`:
- Around line 16-20: The package exports map in the queue package has the same
condition-order issue as the pi package: the `exports["."]` object currently
lists `import` before `types`, which can affect TypeScript `node16`/`nodenext`
resolution. Update the `exports` entry in `package.json` so `types` is listed
before `import` (matching the pattern used in `schema`), while keeping the same
targets for `./dist/index.d.ts` and `./dist/index.js`.
In `@packages/runtime/package.json`:
- Around line 11-15: The exports map in the package manifest has "import" before
"types", which can lead to incorrect type resolution under node16/nodenext.
Update the package.json exports entry for "." so that the "types" condition is
listed before "import" and keep "default" unchanged; use the existing exports
block in packages/runtime/package.json as the target for the reorder.
In `@packages/sandbox/package.json`:
- Around line 16-20: The package export map in the root "." entry has the same
key ordering issue as the other package manifest: reorder the conditions so
"types" comes before "import" in the exports object, matching the pattern used
in the referenced package.json files. Update the export entry in the package
manifest accordingly without changing the values.
In `@packages/schedule/package.json`:
- Around line 16-20: The package export map in the schedule package has the same
key ordering issue as the other package configs: the subpath export under the
main "." entry lists "import" before "types". Reorder the keys in the
package.json export definition for the "." entry so it matches the convention
used in packages/schema/package.json, keeping the same values but placing
"types" before "import".
In `@packages/server/package.json`:
- Around line 16-20: The package export map in the server package has the same
ordering issue as the other package.json files: the export entry under the "."
key places "import" before "types". Update the exports object in
packages/server/package.json so the "types" field comes before "import",
matching the ordering used in packages/schema/package.json and the other package
manifests.
🪄 Autofix (Beta)
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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: dfca589a-32e9-430e-8776-cbb10cd49b1b
📒 Files selected for processing (31)
packages/adapter/package.jsonpackages/aigateway/package.jsonpackages/analytics/package.jsonpackages/api/package.jsonpackages/cli/package.jsonpackages/client/package.jsonpackages/coder-tui/package.jsonpackages/coder/package.jsonpackages/config/package.jsonpackages/create-agentuity/package.jsonpackages/db/package.jsonpackages/email/package.jsonpackages/genesis/package.jsonpackages/hono/package.jsonpackages/keyvalue/package.jsonpackages/migrate/package.jsonpackages/pi/package.jsonpackages/queue/package.jsonpackages/runtime/package.jsonpackages/sandbox/package.jsonpackages/schedule/package.jsonpackages/schema/package.jsonpackages/server/package.jsonpackages/storage/package.jsonpackages/stream/package.jsonpackages/task/package.jsonpackages/telemetry/package.jsonpackages/test-utils/package.jsonpackages/vector/package.jsonpackages/vite/package.jsonpackages/webhook/package.json
📜 Review details
⏰ Context from checks skipped due to timeout. (16)
- GitHub Check: Linux distro install smoke
- GitHub Check: Native install (Linux)
- GitHub Check: Native install (macOS)
- GitHub Check: Installer scenarios
- GitHub Check: Bun version checks
- GitHub Check: Agentuity - docs-docs
- GitHub Check: Windows WSL CLI Smoke Test
- GitHub Check: Framework Demo Tests
- GitHub Check: Package Installation & Usage Test (node)
- GitHub Check: Queue CLI Tests (node)
- GitHub Check: Queue CLI Tests (bun)
- GitHub Check: Service Client Smoke Tests
- GitHub Check: Package Installation & Usage Test (bun)
- GitHub Check: Migrate Chain (v1 → v2 → v3)
- GitHub Check: Pack & Upload
- GitHub Check: Build
🧰 Additional context used
📓 Path-based instructions (9)
packages/vector/**/{package.json,bunfig.toml}
📄 CodeRabbit inference engine (packages/vector/AGENTS.md)
packages/vector/**/{package.json,bunfig.toml}: Build the package usingbun run buildcommand
Runbun run typecheckfor type checking before publishing
Files:
packages/vector/package.json
packages/vector/**/package.json
📄 CodeRabbit inference engine (packages/vector/AGENTS.md)
Depend on
@agentuity/adapter,@agentuity/client,@agentuity/config, and zod; do not depend on@agentuity/core
Files:
packages/vector/package.json
packages/sandbox/**/package.json
📄 CodeRabbit inference engine (packages/sandbox/AGENTS.md)
Declare dependencies on
@agentuity/adapter,@agentuity/api,@agentuity/config,@agentuity/client, and zod in package.json
Files:
packages/sandbox/package.json
packages/email/**/package.json
📄 CodeRabbit inference engine (packages/email/AGENTS.md)
packages/email/**/package.json: Build the package usingbun run buildcommand
Maintain dependencies on@agentuity/adapter,@agentuity/client, and@agentuity/configwithout a direct@agentuity/coredependency
Files:
packages/email/package.json
packages/keyvalue/**/package.json
📄 CodeRabbit inference engine (packages/keyvalue/AGENTS.md)
Declare dependencies on
@agentuity/adapter,@agentuity/client,@agentuity/config, and zod in package.json
Files:
packages/keyvalue/package.json
packages/queue/**/package.json
📄 CodeRabbit inference engine (packages/queue/AGENTS.md)
Use zod,
@agentuity/adapter,@agentuity/client, and@agentuity/configas dependencies
Files:
packages/queue/package.json
packages/webhook/**/package.json
📄 CodeRabbit inference engine (packages/webhook/AGENTS.md)
Depend on
@agentuity/adapter,@agentuity/client,@agentuity/config, and zod packages
Files:
packages/webhook/package.json
packages/task/**/package.json
📄 CodeRabbit inference engine (packages/task/AGENTS.md)
packages/task/**/package.json: Build the package usingbun run buildcommand
Clean build artifacts usingrm -rf dist
Depend on@agentuity/adapter,@agentuity/client,@agentuity/config, and zod for task service functionality
Files:
packages/task/package.json
packages/coder/**/package.json
📄 CodeRabbit inference engine (packages/coder/AGENTS.md)
Maintain dependencies:
@agentuity/adapter,@agentuity/api,@agentuity/client,@agentuity/config,@agentuity/sandbox, and zod
Files:
packages/coder/package.json
🧠 Learnings (1)
📚 Learning: 2026-03-27T23:18:58.450Z
Learnt from: jhaynie
Repo: agentuity/sdk PR: 1292
File: packages/keyvalue/package.json:3-3
Timestamp: 2026-03-27T23:18:58.450Z
Learning: In the agentuity/sdk monorepo, subpackage `package.json` files under `packages/` (e.g., `packages/keyvalue`) are allowed to depend on other workspace packages (such as `agentuity/server`) and are not limited to only `agentuity/core` and `zod`. Also, if a subpackage uses `bunx tsc --build --force` as its build script, treat it as a valid/intentional build command and do not flag it as a dependency/build-script violation.
Applied to files:
packages/cli/package.jsonpackages/adapter/package.jsonpackages/vector/package.jsonpackages/schema/package.jsonpackages/api/package.jsonpackages/sandbox/package.jsonpackages/email/package.jsonpackages/keyvalue/package.jsonpackages/queue/package.jsonpackages/client/package.jsonpackages/db/package.jsonpackages/server/package.jsonpackages/schedule/package.jsonpackages/aigateway/package.jsonpackages/test-utils/package.jsonpackages/migrate/package.jsonpackages/config/package.jsonpackages/stream/package.jsonpackages/runtime/package.jsonpackages/webhook/package.jsonpackages/pi/package.jsonpackages/vite/package.jsonpackages/task/package.jsonpackages/hono/package.jsonpackages/coder-tui/package.jsonpackages/create-agentuity/package.jsonpackages/coder/package.jsonpackages/genesis/package.jsonpackages/analytics/package.jsonpackages/telemetry/package.jsonpackages/storage/package.json
🔇 Additional comments (10)
packages/adapter/package.json (1)
11-15: LGTM!packages/api/package.json (1)
11-15: LGTM!packages/test-utils/package.json (1)
9-13: LGTM!packages/client/package.json (1)
11-15: LGTM! Correct order (typesfirst,defaultlast).packages/config/package.json (1)
11-15: LGTM! Correct order (typesfirst,defaultlast).packages/webhook/package.json (1)
16-20: 🎯 Functional CorrectnessNo change needed. The
exportskey order here is fine, and the package already depends on@agentuity/adapter,@agentuity/client,@agentuity/config, andzod.> Likely an incorrect or invalid review comment.packages/vite/package.json (1)
11-15: 🎯 Functional CorrectnessNo change needed in
packages/vite/package.json. Theexportskey order is already consistent with several sibling packages, sotypesdoes not need to move first.> Likely an incorrect or invalid review comment.packages/genesis/package.json (1)
10-35: LGTM!packages/storage/package.json (1)
16-49: LGTM!
typesis correctly ordered first in every conditional block (nestedbun/node/defaultand each subpath), consistent with TypeScript's requirement.packages/schema/package.json (1)
16-20: LGTM!
Reorder conditional export keys so TypeScript resolves declaration files before runtime entrypoints, matching @agentuity/core conventions. Co-authored-by: Cursor <cursoragent@cursor.com>
Summary
"default"export conditions to 31@agentuity/*packages that previously defined only"import"(and"types") in their export mapsERR_PACKAGE_PATH_NOT_EXPORTEDwhen loading SDK packages via Node or tsx — for exampleimport '@agentuity/core'through tsx, which failed because@agentuity/adapter(and other dependencies) had import-only exports@agentuity/coreand@agentuity/drizzle, which already used"default"Test plan
node -e "require('@agentuity/adapter')"→ERR_PACKAGE_PATH_NOT_EXPORTEDnode -e "require('@agentuity/core')"succeedsbun x tsx -e "import '@agentuity/core'"succeedsbun x tsx -e "import '@agentuity/server'"andimport '@agentuity/genesis/hono'succeedbun -e "import '@agentuity/core'"Fixes #1613
Made with Cursor
Summary by CodeRabbit
defaultexport targets to many packages, improving resolution whendefaultconditions are used.importanddefaultresolve predictably.