fix(eve-extension): rebuild on eve 0.25 dist extension format - #13
Merged
Conversation
Re-scaffold the package with eve 0.25's extension packaging (npx eve extension
init) and move the extension source over unchanged. eve 0.25 ships prebuilt
dist/extension + a compatibility manifest instead of source the consumer
recompiles, and rejects the old format at discovery ('must declare
eve.extension.dist').
This fixes installing the extension from npm: the compiled dist resolves
@upstash/agentkit-sdk from the extension's own package, so consumers no longer
need to install the sdk themselves (verified end-to-end in a standalone pnpm
consumer against the packed tarball: tools, dynamic search, chat capture).
Consumers still declare @upstash/redis - their own mount file imports the s
schema builder from it.
Also bumps eve to ^0.25.2 across the repo (single lockfile copy; the eve
adapter's API is unchanged 0.24->0.25, peer range stays >=0.24.0) and keeps
the eve peer of the extension as the scaffold's wildcard - the built manifest,
not the range, is the compatibility tie.
Known upstream issue (not ours): eve dev fails to load extensions installed
as real directories (npm/yarn hoisted layouts) - its dev-snapshot module-map
uses a relative ../../node_modules path. pnpm symlink installs and production
eve build both work.
…earch A bare mount needs no extra installs; the redis package is required only when the consumer's own mount file imports the s schema builder for search config.
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.
Re-scaffold the package with eve 0.25's extension packaging (npx eve extension init) and move the extension source over unchanged. eve 0.25 ships prebuilt dist/extension + a compatibility manifest instead of source the consumer recompiles, and rejects the old format at discovery ('must declare eve.extension.dist').
This fixes installing the extension from npm: the compiled dist resolves @upstash/agentkit-sdk from the extension's own package, so consumers no longer need to install the sdk themselves (verified end-to-end in a standalone pnpm consumer against the packed tarball: tools, dynamic search, chat capture). Consumers still declare @upstash/redis - their own mount file imports the s schema builder from it.
Also bumps eve to ^0.25.2 across the repo (single lockfile copy; the eve adapter's API is unchanged 0.24->0.25, peer range stays >=0.24.0) and keeps the eve peer of the extension as the scaffold's wildcard - the built manifest, not the range, is the compatibility tie.
Known upstream issue (not ours): eve dev fails to load extensions installed as real directories (npm/yarn hoisted layouts) - its dev-snapshot module-map uses a relative ../../node_modules path. pnpm symlink installs and production eve build both work.