post v0.2.x retrospective (next sprint.. 👀 ) #2
Description
Hi 👋🏻 I'm Doka, the original creator of LazyPrisma :)
I started this as a small side project after running into a bunch of small pain points with Prisma ORM at work.
I wanted somehting in the spirit of LazyGit or LazyDocker, but focused specifically on making Prisma workflows smoother
I'm genuinely grateful that people have taken an interest in the project.
thanks to that, I've been able to keep iterating on it and ship the v0.2.x release 👍🏻 👍🏻
so now that v0.2.x is out, I wanna do a quick retrospective
As LazyPrisma has grown, the TUI side has started to feel a bit too tightly coupled with the core Prisma concerns,
the current UI stack feels heavier than it needs to be and the project is slowly drifting towards TUI tweaks and polish rather than the Prisma focused tooling it was originally meant to prioritise.
so I'm using the issue to track what I'd like to tackle next.
you can think of it as a rough next sprint plan, even tho I'm not running this with strict sprint cycles 😄
- I think, we need to reduce the TUI coupling and move most UI concerns into LazyTUI
Right now, the TUI dependency graph feels a bit too deep and tightly coupled, and it's taking up more space than it probably should in LazyPrisma.
It also feels like we're leaning to heavily on a UI stack that ended up carrying a lot of legacy from the termbox → tcell migration path.
The plan is to lean more on the LazyTUI project and treat it as the proper UI framework layer, so LazyPrisma can focus on Prisma workflows instead of UI mechanics
This also means existing UI quirks should ideally be fixed in LazyTUI rather than patched inside LazyPrisma, like when tab switching doesn't restore the previous panel offset properly..
If we go down this route, we'll need to be careful about backwards compatibility at the framework level.. 😓
- I'd like to tighten up real world validity checks beyond the "migrations are the source to truth" assumption.. lol
the tool currently assumes that the migrations in the repository accurately represent the target database state, which matches Prisma's happy path
but in real world setups, that assumption doesn't always hold..
A common case is migration from legacy ORMs into Prisma or having schema changes happen outside the migration history..
when that happens, prisma migrate dev errors can be hard to interpret and LazyPrisma doesn't currently provide great feedback
what I'd like to add here is a validation mechanism that checks the target DB vs the schema DB using the same approach Prisma uses internally, so we can surface drift in a more actionable way
- I think down.sql generation should be an automated workflow so LazyPrisma can properly have an identity as a migration management tool!
I'd like to build a more automated mechanism for generating down.sql, similar to how we treat up migrations.
this probably needs some DBMS specific tho, because the right strategy may differ across database supported by Prisma
not sure... yet whether the best approach is like below,
- parsing migration SQL properly
- using DBMS specific templates or... a hybrid strategy(diff + heuristics)
but the end goals is the same,
make down migrations less manual, less error-prone, and easier to reason about
- I'd liek to set up a proper i18n module for multi-language support
Right now, most UI text is basically hardcoded in Enlgish, which was fine early on, but I've thought about this a fair bit, and since I'm Korean myself, I've always had multi-language support in mind at same point
the goal is to have a clean i18n layer without turning the codebase into a mess.
Ideally, adding a new language should be as simple as dropping in a new translate file.
I had a quick look at how LazyGit handles this as well, and it seems like they've got a pretty similar approach already so we can probably take some inspration from there..