alkdev/dbtype
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: resolve all open architecture questions with ADRs 009-014

Browse Source 
Resolve OQ-01 through OQ-10 with formal ADRs and update all architecture
docs to reference decisions. Add two new tracked questions (OQ-11, OQ-12)
surfaced during review.

ADR-009: Keep FooRelations naming convention for relation entries
ADR-010: One module per database, include derived schemas by default
ADR-011: Support JSX/TSX as ergonomic authoring layer
ADR-012: Always .returning() with graceful fallback per dialect
ADR-013: Adapter generates relations from module entries (no <relation> element)
ADR-014: Leverage drizzle-kit for migrations, no native migration generator

Also upgrades elements.md, hosts.md, repo-adapter.md status to stable,
clarifies OQ-06 as design clarification, and specifies MySQL .returning()
detection mechanism in ADR-012.
This commit is contained in:
glm-5.1
2026-05-23 12:47:55 +00:00
parent d4fd67f4d2
commit 98764086f4
12 changed files with 481 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/architecture/elements.md
View File

@@ -1,6 +1,6 @@
---
status: draft
last_updated: 2026-05-22
status: stable
last_updated: 2026-05-23
---
# Elements: UJSX Element Definitions
@@ -235,9 +235,9 @@ interface TableMeta {
1. ~~Should column elements support `inner` TypeBox schemas?~~ **Resolved — Yes. ADR-007: flat props for common cases, `inner` as escape hatch for custom validation.** The `inner` prop is now documented in the column props table.
2. **Should `<table>` accept `extraConfig` props?** Drizzle tables accept a third callback argument for indexes and unique constraints defined in terms of column references. How does this map to element props?
2. **Should `<table>` accept `extraConfig` props?** Drizzle tables accept a third callback argument for indexes and unique constraints defined in terms of column references. How does this map to element props? (See [OQ-11](open-questions.md))
3. **Should we support JSX file extensions?** The current probe uses `h()` calls. JSX syntax (`.tsx` files with `jsxImportSource: '@alkdev/ujsx'`) would be more ergonomic for authoring but requires build configuration.
3. ~~**Should we support JSX file extensions?**~~ **Resolved — ADR-011**. JSX/TSX is supported as an ergonomic authoring layer. JSX desugars to `h()` calls via `jsxImportSource: '@alkdev/ujsx'`. The `h()` API remains the universal fallback. TSConfig must set `jsx: 'react-jsx'` and `jsxImportSource: '@alkdev/ujsx'`.
## References