I guess I should expand on my initial reaction...
1. this takes something fast in JS and makes it slow... JSON stringify/parse functionality is very fast in JS generally speaking. Adding this overhead makes it slow, for very little gain.
2. it's using decorators and not really documenting if it's TS, legacy or the current stage-2 decorators proposal. The fact that the repo seems to indicate typescript leads me to believe it's TS based. If this library is TS meant to work with TS, then why not just rely on TS signatures?
3. given the additional overhead vs. just using TS types for code comparability, it's dubious if this is any faster, better or slower for validation vs Joi and any number of existing validation frameworks.
4. the syntax is really noisy. It seems like it's inspired by the ASP .Net Model validation patterns in some ways.
About the only place I might consider this would be within the context of a node based API service, and going back to the third issue, I'm unconvinced this is any better than any number of input validation tools already in existence, or that it's any easier to adapt in that context. I would suggest adding some metrics/testing for seige on an API with various validation tooling including this one in place, including valid and invalid cases one and more layers deep into an object structure.
https://github.com/pichillilorenzo/jackson-js/issues/1