Automatic Collection/Global types (+ making type generation redundant)

[echocrow]

Currently, hooks on Collections and Globals are predominantly typed as any, as Payload cannot infer the shape of the doc.

For example:

const Example: CollectionConfig = {
  slug: 'examples',
  fields: [{ name: 'name', type: 'text'}],
  hooks: {
    afterChange: [({doc}) => {
      // 😕 `doc` typed as `any`
    }],
  },
}

In order to infer or cast the type of a collection, a separate type generation process needs to be run via payload generate:types.

However, I believe there might be a way to automatically infer the type of a given collection, based on the shape of its field values and other properties. The idea would be similar to what tRPC is doing, where the type is automatically inferred from its own definition - no code generation required.

These automatically inferred types could then be fed into the hooks of the same definition, allowing for stricter typed doc variables.
The same inferred types - perhaps even from a global Payload config level - could further be reused to benefit or drastically simplify #1319 for a more strictly typed Local API.

That said, I think this would require a different approach to typing globals and collections. Declaring…

const MyCollection: CollectionConfig = {/* ... */}

…basically erases any further type info from TypeScript.

Instead, I reckon these would need to be declared

• either via a noop function (whose purpose is purely checking and inferring types, and providing IDE completion),
• or maybe via TypeScript 4.9's upcoming satisfies operator.

The latter is still in beta though, and the former might offer more granular control in the future.

What this could look like:

import { collection } from 'payload'

const SomeCollection = collection({
  // We still get auto-completion for required/known fields, like we did before.
  slug: 'examples',
  fields: [{ name: 'name', type: 'text'}],
  hooks: {
    afterChange: [({doc}) => {
      // `doc` typed as {id: string, name: string, ...}
    }],
  },
})

export type ISomeCollection = typeof SomeCollection
// There is probably a better naming convention for this; personally not a fan of the `I` prefix/suffix.
// Maybe the collection variable goes camelCase, and the type goes PascalCase?
// Or maybe there is no need to separately export the resulting type, as its just a `typeof` away anyway?

export default SomeCollection

[echocrow]

If there is any interest in this, happy to help out with this!

If so, to determine feasibility, would it make sense to start with a proof of concept for a subset of field types first?

[reiv]

I don't think you can get around type generation here, since you also need to account for fields being added/modified dynamically at runtime, e.g. as a result of plugins. The interesting part would be to get Payload to automatically pick these types up where possible (maybe some type of mapping from slugs to generated types).

[echocrow]

good call re plugins

I reckon most implicit core-Payload fields (i.e. those added when setting auth: {...} or upload: {...} etc. on the collection) can be taken care of relatively easily.

Non-core dynamic fields added by plugins that add fields would be tricky though. While not impossible, I reckon those final types could only be derived from the Payload config, but not at the collection definition level. And as such, to solve the hook typing issue, types need to be casted, again. (plus now the circular import is also back again.)

Alternatively, plugins could export a TS type that extends the global/collection type the same way the implementation extends the global's/collection's config. Also not exactly great though, as, in a way, that's also just type casting in disguise, and adds extra burden to plugin dev.

Alternatively-alternatively, these inferred types do not replace type gen, but only offer typing for the individual hooks. would then be a tradeoff between typing doc as any vs typing as an interface that has all fields, except for dynamic plugin-based fields. 🤷🏼

[echocrow]

Thinking on this further:

There is yet another possible way around this, taking inspiration from how e.g. SvelteKit is solving derived types from declarative code, which are then importable from a generated, gitignored $types definition file.

Here, this approach would build on top of the existing type generation, and thus also account for plugins. It wouldn't need to be quite as complex as SvelteKit's usecase, and could probably be implemented as an incremental feature.

In theory, this approach could look sth like:

• a .payload/$types.d.ts is generated during dev/build, mostly leveraging Payload's already existing type generation
  • similar to SvelteKit, this file should probably be gitignored, and be listed as entry in rootDirs or typeRoots in the TS config?
• a noop function can be used to define globals & collections
  • internally, this function can read the generated types defined in $types, and, based on a matching slug literal, infers the corresponding type onto the outputted result, as well as all relevant doc arguments.

[reiv]

IMO this second approach is a lot cleaner, since there's no extra burden on users and plugin authors except for an (incrementally adoptable) wrapper around the collection and global configs. Setting up the TS config could even be handled in create-payload-app. Adding to prior art, there's a similar technique used in graphql-nexus, which also creates generated types to supplement a GraphQL schema declared as code.

I would love to see this happen and help out if I can, though it's probably best to wait for someone from the Payload team to weigh in if it aligns with their plans.

[echocrow]

agreed - it's probably also the lowest-hanging fruit given already existing tooling. the only downside I'm seeing is more need for codegen - which some people don't, and others would rather avoid.

as per above, would also love to see this happen and help out if there is any interest from the Payload team