undefined | Better HN

0 pointsWorldMaker8mo ago0 comments

Promise<T> is not T and Typescript's type system will catch that in most cases with a simple type assertion (add a type to the function return; add a `satisfies` check somewhere).

If it isn't catching it often enough, without a lot more extra type assertions, you may be missing a Typescript strict flag like noImplicitAny. (In general I find that I prefer the full `"strict": true` in the compilerOptions of tsconfig.json and always write for all strict checks.)

Also if your codebase is still relying on "explicit" `any`, try `unknown`.

Also, yeah Knex doesn't look like the best ORM for a Typescript codebase. Typescript support in Knex is clearly an after thought, and the documentation admits it:

> However it is to be noted that TypeScript support is currently best-effort.

0 comments

renewiltord8mo ago

Yeah, the codebase in question was using an “insert into db but do not check result and let exceptions inform” pattern. It was probably transformed from JS at some point which is why it used Knex I must guess.

So I suppose I should have found some condition to force use of return values and then unleashed Claude code to fix up linting errors.

It’s rarely a GetX resulting in a Promise<T> that’s mismatched and more an insertX followed by an insertY on the same transaction without awaiting the first insertX that’s the problem. Makes it a heisenbug.

I wouldn’t mind it if the linter was oxlint speed but eslint was a 5 minute affair on the codebase. It’s sort of a Moravec’s Paradox of its own: web development is much more complex than the HFT strats we deployed (which could compile and sim something faster than this can lint).

I suppose I can’t blame the query builder on the tool choice but they were pretty stuck on Knex by then.

Your advice is appreciated. Thank you.

WorldMakerOP8mo ago

Yeah, that's about the point where I would have started mandating every insert be awaited and not just "fire and forget" (or "let the unhandled promise rejection handler sort it out"). Take the linter's advice there and do it everywhere. Would solve a lot more timing heisenbugs and race condition uncertainty, in my experience.

Also yes, eslint is quite slow on larger codebases, but getting faster.

I've more and more using `deno lint` which is similar to oxlint (also Rust based, also trying to be more or less similar to eslint with certain "presets" available) because I mostly like its typescript "required" opinions (I don't configure it much beyond its out of the box configuration). You can use `deno lint` just fine even if you aren't using deno as a runtime.

I think if I was working on a production Node app with a large codebase right now I'd consider `deno lint` or `oxide` as first pass in the inner developer loop and `eslint` configured with the same presets as a CI-mostly second pass.

j / k navigate · click thread line to collapse