Compile `drizzle-orm` end-to-end via `perry.compilePackages`

[proggeramlug]

Tracking issue for landing drizzle-orm (https://github.com/drizzle-team/drizzle-orm) as a perry.compilePackages target.

Surfaced from a Medusa-vs-Perry compatibility study (#419 was filed from the same study). The takeaway: legacy Node ORMs (MikroORM, TypeORM) are decorator + Reflect.metadata + Proxy-driven and are a multi-person-year shim job that locks Perry to upstream cadence. Drizzle was built specifically for AOT/edge runtimes (Workers, Bun, Deno) — same constraints Perry has — and is the natural Perry-side choice.

Why Drizzle (vs. shimming MikroORM/TypeORM/Prisma)

• Schema is plain TS values — pgTable("users", { id: serial(...), name: text(...) }). No decorators, no Reflect.metadata, no runtime class generation.
• Query builder composes at the type level — TS magic, not runtime magic. The compiled output is just method chains over an object.
• Migrations are dev-time (drizzle-kit) — the migration generator never has to live inside the produced binary.
• No ORM identity-map / unit-of-work — explicit await db.insert(...), no surprise side effects, AOT-friendly.
• Already runs on Cloudflare Workers, Bun, Deno — every AOT/edge runtime Drizzle-team had to support gave Perry a head start.
• Drivers Drizzle uses are exactly the ones perry-stdlib already ships: pg, mysql2, sqlite. So the wire layer is in place.

Prisma and Kysely are noted alternatives. Kysely is a smaller-scope follow-up worth considering (query builder only, no schema/migrations — even more AOT-natural). Prisma does not fit Perry's single-binary model (separate Rust query engine binary) and is out of scope here.

Scope

End-to-end means: user does npm install drizzle-orm postgres (or pg), adds "compilePackages": ["drizzle-orm"] to package.json, writes a standard Drizzle program (schema + queries), runs perry compile app.ts -o app && ./app, and gets a single-file native binary that talks to a real Postgres.

Likely shake-out areas:

1. drizzle-orm source compilation — Drizzle is mostly TS, no native bindings. Most should compile out of the box because the lib was already engineered to avoid eval, Function(), runtime metadata. Expect individual TS-subset features each module trips over (the standard compilePackages shake-out, same shape as Compile ink (React-based TUI framework) end-to-end via perry.compilePackages #348).
2. Driver glue — Drizzle's pg-core / mysql-core / sqlite-core hand off to the underlying client. Need to verify the existing pg, mysql2, better-sqlite3-shaped clients in perry-stdlib line up with what Drizzle calls.
3. Type-level query DSL — purely a TS-compile-time concern; Perry uses SWC for parsing and shouldn't have a problem with the heavy generic gymnastics, but worth a real test.
4. drizzle-kit (migrations) — separate concern, not strictly required to be Perry-compiled (it's a dev tool the user runs from Node). Could be a follow-up if there's interest.

Acceptance

• Schema definition + insert/select/update/delete + a relation join in a 50-line program compiles via perry compile, produces a single-file native binary, runs against a real Postgres, and matches the same program under node --experimental-strip-types.
• One of: pg, mysql2, sqlite drivers verified end-to-end. Others as follow-up.
• Whatever shake-out fixes are needed in perry-codegen / perry-stdlib to make the dependency tree compile cleanly, land them under this umbrella.

Out of scope (separate follow-ups)

• drizzle-kit (migration generator) compiling natively — it's a dev-time tool; users can run it from Node.
• Kysely as a compilePackages target — separate, smaller-scope tracking issue.
• Shimming MikroORM / TypeORM / Prisma — explicitly not the path; those are the legacy-Node lineage that Perry's stdlib selections (fastify, pg, ws over their heavier siblings) have already opted out of.
• A Perry-native ORM written from scratch — bigger lift than wiring Drizzle and competes with a thriving library; skip unless Drizzle turns out to be unworkable.

Strategic context

Companion to a Hono compilePackages tracking issue (filed alongside this one). Together they cover the modern AOT-friendly TS backend stack — the same selection that Workers/Bun/Deno users have converged on for the same reasons Perry has.

[proggeramlug]

Smoke compile result

A minimal Drizzle smoke (50 lines: schema with pgTable/serial/text, drizzle() over a pg client, one select().from(...).where(eq(...))) was attempted in a fresh project with compilePackages: ["drizzle-orm"] and drizzle-orm@0.36.4.

HIR + per-module codegen succeed. Perry parses, lowers, and emits object files for all 106 modules in the dep graph (drizzle-orm + pg). The build fails at the link step with undefined cross-module symbols.

Root cause: renamed exports lose their alias name

The clearest example surfaced from drizzle-orm/version.js:

// drizzle-orm/version.js
var version = "0.36.4";
// ...
export {
  version as npmVersion
};

drizzle-orm/tracing.js imports the alias name (import { npmVersion } from './version.js'). At link time:

Undefined symbols for architecture arm64:
  "_perry_fn_node_modules_drizzle_orm_version_js__npmVersion", referenced from:
      ___perry_wrap_extern_node_modules_drizzle_orm_version_js__npmVersion
      in node_modules_drizzle_orm_tracing_js.o

Inspecting the actual object file:

$ nm node_modules_drizzle_orm_version_js.o | grep -iE 'version|npmversion'
___perry_init_strings_node_modules_drizzle_orm_version_js
_node_modules_drizzle_orm_version_js__init

The wrapper for the renamed export — _perry_fn_node_modules_drizzle_orm_version_js__npmVersion — was never emitted on the definition side. The reference side (tracing.js) correctly looks up by the alias name. The mismatch is in codegen: when an export uses as <alias>, Perry emits the symbol under the internal binding name (version), not the public alias name (npmVersion).

Other failures in the same build follow the same shape — TableName, ViewBaseConfig, etc. — all imported under names different from the local declaration in their defining file. drizzle uses this as rename pattern heavily in its barrel exports, so this is the dominant blocker for compiling the package.

Other observations

• All 106 modules parsed and lowered without HIR errors. No U006s, no syntax issues — drizzle's pgTable("users", { id: serial(...).primaryKey(), ... }) plain-TS schema form is fully accepted.
• The schema-as-values pattern (no decorators, no Reflect.metadata) confirms the structural fit. Once renamed-export codegen is fixed, this is likely a near-end-to-end run.

Suggested narrow fix

In the codegen pass that emits per-module export wrappers (__perry_wrap_extern_* / _perry_fn_*), use the public export name (the as <alias> if present) for the emitted symbol, not the local binding name. Spot-check by linking a 5-line repro:

// a.js
var x = 1
export { x as renamed }
// b.js
import { renamed } from './a.js'
console.log(renamed)

This should reproduce the same Undefined symbols: _perry_fn_*__renamed failure.

Status

• ✅ Drizzle is structurally Perry-compatible (no decorators, no metadata reflection, schema as values, query builder as type-level magic).
• ❌ Renamed-export codegen bug blocks the link.
• 🟡 No further unknowns surfaced beyond the renamed-export issue. Once that lands, the next failure mode (if any) becomes visible.

[ZQun]

Using drizzle-orm is a very good direction. Judging from the official test data, drizzle-orm's performance is very strong. If it can be combined with perry, I believe there will be a big breakthrough. I look forward to providing solutions in this direction!

[proggeramlug]

Status snapshot as of v0.5.585 + breakdown of what's left.

✅ Done in this release cycle

• v0.5.576 — duplicate-symbol __perry_wrap_perry_unknown_func (multi-module link blocker for any 5+ module program; drizzle has many)
• 6-line drizzle schema (pgTable users { id, name, age }) compiles + runs end-to-end

🔁 Strategy change: pure-TS drivers

Per direction, drizzle should use @perryts/postgres and @perry/mysql (pure-TS wire-protocol drivers in the PerryTS org) instead of perry-ext-pg / perry-ext-mysql2 (sqlx-backed). Reason: pure-TS dep tree exercises perry's full compilePackages path — drizzle + driver + perry-stdlib net.Socket — without bypassing perry's net pipeline through Rust. Native drivers stay around as opt-ins via the well-known table; drizzle just gets a different default-stack for its end-to-end demo.

❌ What's left

Filed as sub-issues:

• Drizzle acceptance: 50-line program against real Postgres via @perryts/postgres #488 — 50-line program against real Postgres via @perryts/postgres. Schema + insert/select/update/delete + relation join. The substantial unknown work.
• Drizzle: 50-line program against real MySQL via @perry/mysql (followup to #488) #489 — Same against real MySQL via @perry/mysql (followup to Drizzle acceptance: 50-line program against real Postgres via @perryts/postgres #488).

This issue stays open as the umbrella; closes when #488 lands (#489 can ship later as a followup).