shared packages loaded indirectly result in duplicate types. #838
Replies: 2 comments 3 replies
-
You can have two types with the same name but with different fields in your code. They might be referenced by different resolvers thus appearing in different schemas but still sharing the same metadata storage. It can even difference only by nullability of the field. Traversing all the schema just to make sure the duplicate is not a duplicate is a complicated and error-prone thing that just masks your issues in the codebase. I still not fully understand your use case of "shared packages loaded indirectly". Do you have two types |
Beta Was this translation helpful? Give feedback.
-
|
At the core of our product, there's a ´common´ or ´shared´ package which define fundamental types like ´Language´. They are fundamental in the sense that they do not contain any business logic, and can be reused in many places.
Then there's a bunch of other packages which import them.
And finally, those packages, are dependencies of a project which imports all of them.
So for clarity there only is 1 ´Language´ schema in our sources. And we want to reuse it in many different places. Nevertheless, even though we defined 1 ´Language´ schema in this setup, the system tells us it found duplicates. Not what we intended of course.
So, given the fact that these issues only happen for schemas of that core package, it has to do with our multi-level dependency setup. We are running against the limits of the system here.
You would think that the ´import ... from ...´ assures that the same package can only be loaded once and that this will assure that all usages are in essence the same. At this stage we can only guess that we broke something here. Apparently, within a bigger tree of transpiled dependencies something goes wrong. Even though both ´Language´ schemas come from the same source, they are no longer the same according to the system.
But it's really hard to trace back where it goes wrong.
It would be a help if in case of a duplicate schema there would be some more context.
e.g. this schema which I've imported from X is not the same as the one
which I imported from Y.
Or alternatively, it would be a help if you could somehow force the system to handle them as the same type,
If the system fails to see that the schemas are the same, perhaps that shouldn't be the end of it. If the schemas actually have the same name, the same fields, the same decorators, the same optionals, ...
|
Beta Was this translation helpful? Give feedback.
-
TypeGraphQL doesn't know anything about your shared packages nor the imports. TypeGraphQL classes are registered in that global metadata storage when the decorators are evaluated. It should happen on the first import, that's why you can have multiple imports in the same code without any issue. In your case, looks like you have multiple copies on the shared packages spread everywhere in the node_modules. So when node is traversing the imports, it has different copies of the shared packages so it keeps having multiple copiess of loaded modules in the memory, thus having the same type defined twice in the metadata storage, and then different types referenced as the types in resolvers. Unfortunately, I can't see any way of detecting such mess in TypeGraphQL. Try to investigate your deps chain and maybe use a monorepo 😉 |
Beta Was this translation helpful? Give feedback.
-
|
wow you're fast :) I was still editing :-D |
Beta Was this translation helpful? Give feedback.
-
|
we do use a monorepo by the way. We use lerna to build everything and to keep things together using hoisting. |
Beta Was this translation helpful? Give feedback.
-
We sometimes are confronted with error messages indicating that there are multiple types with the same name. In fact, our source base uses shared packages. When imported packages reuse schemas, those schemas are sometimes wrongfully interpreted as different ones.
It makes me wonder, if the name is the same, and their fields and types are the same, shouldn't it somehow detect that these are in fact the same types?
What can we do to avoid this problem? Could we for instance put some kind of unique identifier on them (e.g. a fully qualified name or a serialversionid).
Beta Was this translation helpful? Give feedback.
All reactions