TypeScript type mismatch with Joi (and testing plugins) #35229
Unanswered
webstackdev
asked this question in
RFC
Replies: 1 comment
-
Hey @webstackdev, Some history: In this commit I un-copied the custom types cause I didn't think we needed them. Max redid it in a later commit. If I remember correctly it was something to do with Joi's typing for I'm not sure the status of the |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Since TS support for
gatsby-*
files landed in 4.9, I've been refactoring my core Gatsby files to take advantage of it. I've run into a problem involving types for thepluginOptionsSchema
gatsby-node API method.I think at one point the TS types for Joi (validation library) were out of sync as that project moved out of the @Hapi namespace. The
gatsby-plugin-utils
has a modified set of types and re-exports the Joi object, along with atestPluginOptionsSchema
function.I have some functionality that I implemented in a Joi extension so that it was easier to use template-d error messages. I need the Joi types for
CustomHelpers
,Extension
, andExtensionFactory
which aren't exported from the hard-code version of Joi types ingatsby-plugin-utils
(which removes theJoi
namespace from the typings). The type is available on Joi e.g.Joi.ExtensionFactory
from thejoi
package, but the two sets of typings (Joi's andgatsby-plugin-utils
) have gotten out of sync. The Joi interface forValidationError
has an_original: any
key, where thegatsby-plugin-utils
version has an_object: any
key instead so I get type errors.My interim solution is a local copy of
gatsby-plugin-utils
with modified typings. I think the right solution is to modify the Gatsby typings:Another possibility is to move
packages/gatsby-plugin-util/src/joi.ts
to eitherpackages/gatsby/src/bootstrap/load-plugins/
orpackages/gatsby/src/joi-schemas/
in an appropriate file, and modify the type of the exported Joi object toJoi.Root
. That way there's a central place to manage typings and extensions to the Joi object used in plugin options validation.I'd be happy to push a PR through but opened a discussion because I'm not sure the best route to go. There was some work on plugin option validation to use dot env vars in
gatsby-config
, but it doesn't seem like that work went anywhere and might be reasonably stripped out (note from @mxstbr October 2021 that the functionality was being considered). So I don't think the reason for providing a custom Gatsby-specific type for the Joi object used in plugin option schema validation may still even be relevant.On a tenuously related note:
I plan to create a plugin with a few additional Joi validation testing methods in it. I'm not sure if it'll be useful to a wider audience, but it had me thinking about Gatsby testing plugins generally. I'll end up with a name like
gatsby-plugin-testing-joi
in a vendor namespace. There's lots of variations on the second slug segment for Gatsby plugins now; atesting
one is a suggestion I'd add (e.g.gatsby-testing-joi
). A Jest plugin seems like it could provide drop-in Jest config with all of the piddly files built in and reasonable defaults.Beta Was this translation helpful? Give feedback.
All reactions