Type-graphql: `No metadata found....` Error

[j]

I'm using class-validator and having to bring it in as a dependency as well to add the constraints, but get the annoying console warning:

No metadata found. There is more than once class-validator version installed probably. You need to flatten your dependencies.

I don't want to pass validate: false and I don't want to get into a situation where my validation constraints aren't running due to how it works internally.

[MichalLytek]

Once again, what is your problem? You don't use validation but you don't want to pass validate: false?

No metadata found. There is more than once class-validator version installed probably. You need to flatten your dependencies.

See this for more info:
https://github.com/typestack/class-validator/issues/279

[j]

No, I use validation, so I don't pass validate: false, but I need to add class-validator as a dependency, so seeing that error message worries me because I'm not sure if my own custom validation logic is going to be executed due to multiple class-validator since type-graphql doesn't have it as a peerDependency.

To remove the error, I'd think either type-graphql exports all of the validation decorators or uses strict peerDependency.

[j]

Them having an error makes me believe that they're using a global within class-validator to store metadata, so if type-graphql brings their own class-validator and I bring my own class-validator, leads me to feel that my validation constraints won't be executed due to validate being called within the type-graphql library. It's concerning and makes me worry, that's all.

[MichalLytek]

Yes, the problem is that TypeGraphQL and TypeORM uses global to store the metadata across multiple instances of packages while class-validator have own local storage per package.

So multiple instances of class-validator will result in that error unless you provide your own container for metadata storage. I had a project with separated repo for responses (entities) and inputs (requests) models and separate backend and frontend repos. I did this trick to make it work across multiple modules with npm link:

import * as TypeORM from "typeorm";
import * as ClassValidator from "class-validator";
import { Container } from "typedi";

TypeORM.useContainer(Container);
ClassValidator.useContainer(Container);

export * from "./entities";
export * from "./requests";

I'd think either type-graphql exports all of the validation decorators or uses strict peerDependency.

This doesn't fix the error. Without lerna and hoisting dependencies or using a private npm registry, you will have two node_modules for both project and both will have own instances of class-validator package.

[j]

Okay, hmm. I'm using inversify for my container and yarn workspaces (no lerna).

The error comes from within type-graphql package:

node_modules/type-graphql/node_modules/class-validator/validation/ValidationExecutor.js

Based off the error message, I'd think that if I brought my own class-validator and it was at the root of node_modules (which it is), then the error would go away, but I guess not?

I suppose I'll just play it safe and do manual validation.

[MichalLytek]

I'd think that if I brought my own class-validator and it was at the root of node_modules

Try also npm dedupe but I'm not sure if it works with node_modules in parent directory.
If not, even peer dependency won't work as it checks only local node_modules.

There would be a problem with duplicated graphql-js too even without peer dependency as the instaceof check doesn't work between different instances of module.

I suppose I'll just play it safe and do manual validation.

You can use method or param decorators to create own validation rules, you don't have to do this manually inside each resolver's body.

So you have a few options:

• use dependencies hoisting (maybe yarn workspaces can do that too)
• make a peer dependency on class-validator in your models package and use private npm registry or git to install bundled package without node_modules
• create a PR for class-validator that uses global scoped metadata storage
• use own decorators that imports package from root node_modules

[j]

I oddly get the error even when I dedupe, use resolutions, and have one instance of class-validator.

My mono-repo packages don't have any node_modules, they are all just in the root node_modules directory. node_modules under type-graphql package also doesn't contain class-validator. There's just one.....

I'll look into using my own decorators. I'm also not using TypeORM. So it's interesting to not know what's going on.

[j]

I'm sure it has to do with how I use inversify. I'm creating a container and bootstrapping code there, so my class imports happen before, but I get the error even after I remove useContainer from class-validator.

[j]

@19majkel94 Is it possible now to create a middleware that has the converted inputs/args? If not, it might be cool if there was an option to get the decorated params on a middleware function call then people can bring their own.

[MichalLytek]

I oddly get the error even when I dedupe, use resolutions, and have one instance of class-validator.

If you register your container after evaluating the class decorators, it will have empty metadata storage in the container, so you will see this warning.

Is it possible now to create a middleware that has the converted inputs/args?

Not yet - see #123.

to get the decorated params on a middleware function call then people can bring their own

Custom validation will be supported by vNext and plugins system 😉

[j]

@19majkel94 can't wait for it! :)

[Swatinem]

There is more than once class-validator version installed probably.

The warning message is spot-on!

You depend on an outdated version: https://github.com/MichalLytek/type-graphql/blob/8e112d1c7148623781594a48a029ece4870f11b9/package.json#L27
Whereas when someone imports class-validator in their own code, they will probably use the latest version, which is 0.10.0

[MichalLytek]

I will close this issue for now as it looks like the problem is with how class-validator store the metadata internally and how to cope with splitted packages/monorepo, not about TypeGraphQL and how it uses class-validator.