deprecated onTypeConflict substitution?

[terion-name]

`onTypeConflict` is deprecated. Use schema transforms to customize merging logic.

well, ok. but how to mimic onTypeConflict with transforms? I need literally merge duplicating types and handle this merging process. How to do this via transforms?

[joeflack4]

+1

[stubailo]

@joeflack4 I'm current working on removing this and providing a good alternative; it looks like in the example you provided, onTypeConflict is not really used; only to select the first type that shows up.

@terion-name would it work for you if merging types was the only option and always done? And then if you wanted to remove or rename fields you do that with a transform?

[terion-name]

@stubailo merging types how? Let's assume I have two conflicting types: Article {id title} and Article {id slug}. How merger would merge them? Article {id title slug}? And what if title has different types? Or there are some relations? I don't think automerging will work for most cases. And I really don't understand, why onTypeConflict is deprecated. It is really convenient thing that provides control in complex scenarios (I use it on my gateway that is very complex and onTypeConflict really helps alot)

[dncrews]

@stubailo: what I'm looking for is this "left-first" solution. Is the correct answer to just reverse the array (i.e. order matters, similar to Object.assign)?

[Tehnix]

Did anyone figure out how to replace onTypeConflict with "Use schema transforms to customize merging logic"?

We are simply just checking if you have a conflicting type, and then throwing an error, which'll be caught in our integration-test flow.

[thehappycoder]

I have the same use-case as @Tehnix and I am trying to figure out how to do that with transformations. In my case, the names of root fields in the schemas are not known in advance, so it's probably impossible to implement with transformations.

[fgrehm]

Apparently the option's use got completely removed by @stubailo here :-(

I'm not seeing much use of argument based on this search and mergeSchemas does not seem to be using the argument as well.

[kommander]

I have the same use case as @Tehnix and just put together a tool to also check for field collisions on object types before merging. Would it maybe make sense putting this with the stitching tools?
Here's a diff: master...kommander:feature/add-standalone-find-type-conflict

Otherwise I'll just release it as npm module on its own.

[thehappycoder]

@kommander Did you end up publishing it as a package?

[kommander]

@thehappycoder nope, it ended up as part of the project codebase 😦

[yaacovCR]

onTypeConflict is back in graphql-tools-fork https://www.npmjs.com/package/graphql-tools-fork

[yaacovCR]

Folded into #1306