The problem
Polly's Elysia plugin installs its own nested copy of elysia@1.4.11 inside node_modules/@fairfox/polly/node_modules/elysia. When a consuming app uses a newer Elysia (e.g. 1.4.28), two separate Elysia type systems coexist. The types from Polly's plugin don't match the app's types, and TypeScript's route inference collapses into index signatures — { [x: string]: ... } — instead of properly typed path segments.
The practical consequence: Eden Treaty's treaty(app) loses all route type information. Every route accessor like .api.v1.users becomes Property 'v1' does not exist.
Reproduction
In a consuming app's bun.lock (or equivalent), you can see the duplication:
├── elysia@1.4.28 ← root
├── @fairfox/polly/elysia@1.4.11 ← nested
The Polly package.json declares elysia: ">= 1.4.0" as an optional peer dependency, which is correct. But something in the resolution causes Bun to install a separate copy rather than deduplicating against the root.
Root cause
Polly's published package appears to resolve its own elysia dependency independently. The peer dependency declaration is there, but the package manager still installs a nested copy — likely because of a mismatch between the version range Polly was built against and the version the consuming app uses.
Suggested fix
- Ensure
elysia is only a peer dependency (not also in dependencies or devDependencies in a way that leaks into the published package).
- Rebuild and publish against a recent Elysia (>= 1.4.28) so the types align.
- Verify that
npm pack / the published tarball does not bundle or pin its own Elysia.
Environment
@fairfox/polly: 0.20.0elysia (app): 1.4.28@elysiajs/eden: 1.4.8- Runtime: Bun 1.3.11
- TypeScript: 5.9.3
The problem
Polly's Elysia plugin installs its own nested copy of
elysia@1.4.11insidenode_modules/@fairfox/polly/node_modules/elysia. When a consuming app uses a newer Elysia (e.g. 1.4.28), two separate Elysia type systems coexist. The types from Polly's plugin don't match the app's types, and TypeScript's route inference collapses into index signatures —{ [x: string]: ... }— instead of properly typed path segments.The practical consequence: Eden Treaty's
treaty(app)loses all route type information. Every route accessor like.api.v1.usersbecomesProperty 'v1' does not exist.Reproduction
In a consuming app's
bun.lock(or equivalent), you can see the duplication:The Polly
package.jsondeclareselysia: ">= 1.4.0"as an optional peer dependency, which is correct. But something in the resolution causes Bun to install a separate copy rather than deduplicating against the root.Root cause
Polly's published package appears to resolve its own
elysiadependency independently. The peer dependency declaration is there, but the package manager still installs a nested copy — likely because of a mismatch between the version range Polly was built against and the version the consuming app uses.Suggested fix
elysiais only a peer dependency (not also independenciesordevDependenciesin a way that leaks into the published package).npm pack/ the published tarball does not bundle or pin its own Elysia.Environment
@fairfox/polly: 0.20.0elysia(app): 1.4.28@elysiajs/eden: 1.4.8