kevinmarrec / h3-typebox Goto Github PK

A current nitro project cannot be compiled because of the dependency to h3 0.7.21. h3 had breaking chages with 0.8.0, which leads to compilation errors:

import { eventHandler, setHeaders, sendRedirect, defineEventHandler, handleCacheHeaders, createEvent, getRequestHeader, createError, createApp, createRouter as createRouter$1, lazyEventHandler, toNodeListener } from 'h3';
                                                                                                                                                                                                   ^^^^^^^^^^^^^^
SyntaxError: The requested module 'h3' does not provide an export named 'toNodeListener'

We should at least update the dependency to 0.8.0 and continuously update the h3 dependency until it reaches 1.0.0 in CI/CD. Maybe add renovate to stay up to date?

PS: @kevinmarrec can you add the hacktoberfest label to the repo? Contributions can then be added to the contributors hacktoberfest score :)

When running validateBody (probably also the other helpers), it throws an error in production on vercel-edge (cloudflare workers). Most likely because they restrict certain JavaScript functions like eval(), new Function(), setTimeout([string]), and setInterval([string]), which can execute code generated from strings.

I'm not sure why these functions are needed but it would be better to avoid them.

Hey @kevinmarrec,
great h3 addition, I had no problems with using it so far. As I am pretty new to TypeBox, I wanted to ask, what the best way would be to make sure that only the provided fields are actually on the request?
From a security perspective, it is discussable, but sometimes you want to have paramA, paramB and paramC as query parameter and used validateQuery to define them as string (what query strings always are). If a user now queries the url with paramX, it will not throw an error, as the field will not be verified by typebox.
Is there any way to handle a catch all for all parameters/body entries that are not part of the schema or is this something you would implement in nitro natively?