keystonejs / keystone

The most powerful headless CMS for Node.js — built with GraphQL and React
https://keystonejs.com
MIT License
8.98k stars 1.13k forks source link

Unable to use new `validate.{create|update|delete}` field-level hooks with most built-in fields #9165

Open acburdine opened 4 weeks ago

acburdine commented 4 weeks ago

I looked around for a similar issue/discussion but didn't see one, apologies if this is a duplicate.

At the moment, it appears to be impossible to use the new validate.{create|update|delete} field-level hooks with most of the built-in Keystone field types.

This appears to be due to this list check which asserts the mutual exclusivity of the new validate syntax and the old validate syntax.

Most of the built-in fields define a validateInput check that's automatically added if db.isNullable is set to false or if you specify validation options (example). Attempting to define a custom validate.create/validate.update check results in the following error:

TypeError: "hooks.validate" conflicts with "hooks.validateInput" for the "name" field
    at parseFieldHooks (myapp/node_modules/@keystone-6/core/dist/createSystem-b6c61fe6.cjs.dev.js:3793:50)
    at getListsWithInitialisedFields (myapp/node_modules/@keystone-6/core/dist/createSystem-b6c61fe6.cjs.dev.js:3871:16)
    at initialiseLists (myapp/node_modules/@keystone-6/core/dist/createSystem-b6c61fe6.cjs.dev.js:4305:25)
    at Object.createSystem (myapp/node_modules/@keystone-6/core/dist/createSystem-b6c61fe6.cjs.dev.js:4548:17)

Given that the validateInput/validateDelete syntax has been marked as deprecated (at least code comments seem to indicate that), I expected the built-in fields to allow usage of the new syntax (maybe it would make sense to have them automatically switch based on the presence of the validate object?)

Happy to submit a PR for this, but figured I'd also file an issue.

Keystone Version: latest (6.1.0) Node Version: v20

dcousens commented 4 weeks ago

As mentioned in https://github.com/keystonejs/keystone/pull/9057

This won't be compatible with many of the native field types, but that compatibility can come later.

In other words, I didn't have the time to adapt each native field type, so a pull request is welcome :green_heart: