fix(runtime,cli): resolve optional capability packages from host app context#1573
Merged
Conversation
…app context loadCapabilities() and the CLI serve auto-register did a bare dynamic import of capability packages (e.g. @objectstack/service-ai-studio), which resolves relative to the framework package's own location. A private/optional package linked into the *app's* node_modules (the tenant runtime apps/objectos, or an enterprise objectos-ee install) is invisible there — it failed with "Cannot find package … imported from …/framework/…", so cloud tenants never loaded AI Studio despite declaring the dependency. Resolve via createRequire anchored at process.cwd() (the host app), then import the resolved path; fall back to a bare import for framework-owned packages. Verified: createRequire from the app dir resolves @objectstack/service-ai-studio to its dist; the old framework-relative resolution returns MODULE_NOT_FOUND. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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
2 participants
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.
loadCapabilities()(per-environment kernels, apps/objectos) and the CLIserveauto-register both did a bare dynamicimport(pkg)of optional capability packages. A bare specifier resolves relative to the framework package's own location, so a private/optional package linked into the app'snode_modules— e.g.@objectstack/service-ai-studio, which the framework itself does not depend on — is invisible. It failed withCannot find package … imported from …/framework/…, so cloud tenants never actually loaded AI Studio despiteapps/objectosdeclaring the dependency (and the same for enterprise objectos-ee).Fix
Resolve via
createRequireanchored atprocess.cwd()(the host app), import the resolved path, and fall back to a bare import for framework-owned packages.packages/runtime/src/cloud/capability-loader.ts—importFromHost()helper used for the main provider + extras.packages/cli/src/commands/serve.ts— same host-context resolution for the AI + AI Studio auto-register.Verified
createRequire(<app>/package.json).resolve('@objectstack/service-ai-studio')→ resolves to itsdist; the old framework-relative resolution returnsMODULE_NOT_FOUND.runtime+clibuild clean.Unblocks the cloud multi-tenant path for
@objectstack/service-ai-studio(and any private capability package). Enterprise objectos-ee already works via explicitplugins:[...]registration; this makes the auto-discovery path correct too.🤖 Generated with Claude Code