Consider disallowing primitive booleans for undefined keys in object shape

[scotttrinh]

A query like this:

const q = e.select(e.User, () => ({
  name: true,
  birthdaet: true,
}));

Will type-check (and run) successfully since it treats the typo birthdaet as a computed with the value true. While this is a supported use case, it's rarely an intentional one. If you intend to set a computed to the literal true or false value, the safer way is to use e.bool(true) and e.bool(false) instead of relying on the automatic primitive up-casting in this case.

It seems somewhat controversial to make a big breaking change like this when it's hard to tell the intent of the caller, making it hard to find out if you're accidentally relying on this behavior. Maybe we can hide this behind a --future-no-primitive-computeds flag and fail for any computed that uses a primitive? Or special case this as --future-no-boolean-computeds?

[halindraprakoso]

@scotttrinh Yeah, I'm with you on this. Using a flag sounds like a good way to go.

Like you said, it's probably a pretty rare case for someone to intentionally set a computed to a raw boolean instead of just selecting a field (personally I have hundreds of queries and never do this). So, for the vast majority, a flag would just help catch typos or non-existing/renamed fields. And if someone is doing it on purpose, switching to e.bool(true) is a super quick fix – basically just a tsc run and a few minor tweaks. Seems like a solid, low-impact way to improve type safety here.