This would require a return to the insane generics. I doubt the benefits would outweigh the increased friction on types.

This is also something i was looking for recently. Whilst the meta option is definitely great; being able to have independent types for each table would help keep things a bit more tidy. Can understand why you wouldn't want to go down that route though @tannerlinsley

I found this discussion just before I was going to post about it. I don't like the insane generics thing too (and v7 added more problems with that as we had to define global types per the plugins we used). I would love to hear if someone found a solution to it. currently, I just add more props to meta, but I have no way to understand which types are related...

I do think adding a generic for meta is the solution here

I’m strongly in favor of restoring a per-table meta-type setter. In large codebases where dozens of tables each carry a different row-meta contract, forcing all meta functions into a single merged global interface quickly becomes unmanageable... duplicate definitions and unintended meta callbacks get pulled into tables where they don’t belong.

I don't think this would be so insane if the columnHelper and/or the table hook would accept an optional meta generic.