feat: request validation using handler object syntax validate and validateEvent(event)

[danielroe]

🔗 Linked issue

❓ Type of change

• 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This allows inferring type of event by passing a validate function which needs to return the event (as validated). It's simple and allows any kind of validation, throwing an error if invalid input is provided.

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[codecov]

Codecov Report

Merging #496 (6f2ea16) into main (68ebbf2) will increase coverage by 0.77%.
Report is 1 commits behind head on main.
The diff coverage is 95.90%.

❗ Current head 6f2ea16 differs from pull request most recent head 8029e83. Consider uploading reports for the commit 8029e83 to get more accurate results

@@            Coverage Diff             @@
##             main     #496      +/-   ##
==========================================
+ Coverage   82.41%   83.19%   +0.77%     
==========================================
  Files          31       32       +1     
  Lines        3549     3654     +105     
  Branches      529      545      +16     
==========================================
+ Hits         2925     3040     +115     
+ Misses        624      614      -10     

Files Changed	Coverage Δ
src/utils/request.ts	94.19% <50.00%> (-1.18%)	⬇️
src/event/event.ts	88.76% <83.33%> (+0.19%)	⬆️
src/event/utils.ts	79.80% <97.01%> (+17.12%)	⬆️
src/types.ts	100.00% <100.00%> (ø)
src/utils/body.ts	95.43% <100.00%> (-0.03%)	⬇️
src/utils/symbols.ts	100.00% <100.00%> (ø)

[pi0]

I am wondering if we can alternatively support before:[validate()] to allow multiple validate functions and avoid adding new hook.

[danielroe]

The issue is the typing. It might be possible but will be a lot more complex, to create chainable validators. (So output of one becomes input of another.)

[pi0]

It makes sense for type complexity

I am thinking it could give some overhead for when we want to do body normalization, we actually read the body (and an external library can apply schema normalization). Only returning a boolean + typed Event will cause to loose this information (unless the utils support a context caching mechanism for when we later call useValidatedBody AND we use same validation options) vs before hooks or alike method that can do both validation + context injection like before: [useValidatedBody]

Also, it would be nice if we expose a generic utility async validateEvent to extract this functionality and also make it available for non object syntax usages.

[iainsproat]

Hi, I wish to understand how this change would interact with, or eliminates the need for, the validation options via community packages mentioned in h3's README? https://github.com/unjs/h3#community-packages

[pi0]

Update: Both me and @danielroe need to rethink about whole typing and validation and how it works with downstream (Nitro and Nuxt) types and best type/runtime safely+perf balance which is tricky at the moment. Making it draft until after 1.8 to iterate.