Simplify liveblocks.config.ts generics for the common case

[GuillaumeSalles]

Context

• We receive a lot of support requests about how to type our Presence, Storage, UserInfo, RoomEvent and ThreadMetadata.
• If you need to specify only one generic that is not Presence, the DX is awkward. createRoomContext<{}, never, never, never, { resolved: boolean }>. This used to be okay because Presence and Storage were the core of Liveblocks. With new developers coming to our platform for Comments or Y.js, this happens more and more frequently.
• We introduced the factory pattern (createRoomContext) to let developers use different types per room.
• The relationship between our hooks and generics is not always obvious. For example useBroadcastEvent ( https://github.com/liveblocks/liveblocks.io/issues/1984)

Proposal

I'm still not entirely convinced this is a good idea, but I couldn't come up with something better yet.

Support type overrides with Module Augmentation. Inspired by Slate. The goal would be to support the factory for the advanced use cases but recommend module augmentation as the default in our docs and examples.

Before

// liveblocks.config.ts

type ThreadMetadata = {
   resolved: boolean
}

const client = createClient({ /* ...  */ });

export { } = createRoomContext<{}, never, never, never, ThreadMetadata>(client);

After

// liveblocks.config.ts

module `@liveblocks/client` {
  type ThreadMetadata = {
     resolved: boolean
  }
}

const client = createClient({ /* ...  */ });

export { } = createRoomContext(client);

Other benefits:

• It also works for users that do not use @liveblocks/react. No need to pass generics to enterRoom. It would simplify our docs quite a bit I think.
• We might also re-export our @liveblocks/react hooks directly instead of exporting them from the config? It's starting to make more sense as we're re-introducing LiveblocksProvider. We could provide a code mod for an upgrade? 🤔

[nvie]

This is an interesting idea. Would definitely make things simpler, at the cost of only supporting one room "type" globally for your app. If you want to support multiple room types, you still have the option to stop using module augmentation like this, and switch back to the 5-type-params-form for each room types. So easy for the common case, but an escape hatch for the less-common case.

There are a couple questions we should figure out about this:

• What is the DX going to be like if you don't augment a mandatory type (e.g. you don't specify a Presence type)?
• What is the DX going to be like if you augment a type in an invalid way (e.g. you extend your Storage type with non-LSON data, or you specify a UserMeta shape that isn't compatible)
• What kind of errors will that produce and will they be helpful to pin-point the problem?
• Where will those errors be happening? Those TS errors should be happening inside the user's code base, not in Liveblocks library code (which to a developer lives inside node_modules and many projects have skipLibCheck enabled).
• Does "jump to definition" still work as expected if you want to look up a specific inferred type from a random place in the code base?