Trying to use multiple artefact directories with 9.0.0

[sgwilym]

I was taking a a look at #139 and this interested me:

I would think this will also allow our users to use Relay without using the single artifact directory - is that correct?

I'm not familiar with the history of this restriction, but if it's down to the complexity of managing import paths then yeah as long as names are still globally unique.

As far as I recall this is exactly the issue going on here.

This is very fortunate timing as I'm starting a project in a monorepo where having many artifact directories would be very useful. So I decided to give it a spin:

1. I updated to relay-compiler-language-typescript@v9.0.0
2. I updated to @types/relay-runtime@6.0.7
3. I removed the --artifactDirectory option from my relay compiler command
4. I regenerated the artefacts, which seemed to work well and had no problems with them as far as TS could see.

And then I got stuck. Where relay props are passed down into a child component, Typescript raises errors like the following:

Type '{ readonly slug: string | null; readonly name: string; readonly localId: number; readonly subcategories: readonly { readonly slug: string | null; readonly name: string; readonly localId: number; readonly subcategories: readonly { ...; }[]; }[]; readonly " $fragmentRefs": FragmentRefs<...>; }' is not assignable to type '_FragmentRefs<"ProductListingHero_category">'.
  Types of property '' $fragmentRefs'' are incompatible.
    Type 'FragmentRefs<"ProductListingHero_category">' is not assignable to type '"ProductListingHero_category"'.

I am admittedly not a Typescript expert so it's hard for me to untangle what the issue is here. Any ideas what could be going wrong here?

[alloy]

@ds300 We should give this a try in our codebase (Emission).

[renanmav]

Don't you think that #149 will fix this incompatibility?

[alloy]

@renanmav I’m unsure what part of that you think may fix this, can you elaborate? Theoretically this should already be working afaik.

[renanmav]

[...] readonly " $fragmentRefs": FragmentRefs<...>; }' is not assignable to type '_FragmentRefs<"ProductListingHero_category">'

Now, we splitted into $key that aggregates " $data" and " $fragmentRef" artifacts, such as these:

import { FragmentRefs } from "relay-runtime";
export type TodoApp_viewer = {
    readonly id: string;
    readonly totalCount: number | null;
    readonly " $fragmentRefs": FragmentRefs<"TodoListFooter_viewer" | "TodoList_viewer">;
    readonly " $refType": "TodoApp_viewer";
};
export type TodoApp_viewer$data = TodoApp_viewer;
export type TodoApp_viewer$key = {
    readonly " $data"?: TodoApp_viewer$data;
    readonly " $fragmentRefs": FragmentRefs<"TodoApp_viewer">;
};

_FragmentRefs are no longer emitted.

[ds300]

@sgwilym I saw this temporarily when upgrading our app at Artsy. It seemed like there was a duplicate definition of _FragmentRefs<> being picked up, defined in @types/relay-compiler for some reason. So I updated @types/relay-compiler and the error went away. But then it was pointed out to me that we didn't actually need @types/relay-compiler so I removed it and the problem didn't come back.

In hindsight it might just have been a TS caching issue. So try what I did above, and if that doesn't work we can debug further.

[sgwilym]

@ds300 Another version of @types/relay-runtime had snuck into our yarn.lock and had to be removed manually. After that, everything checks out. Thanks!

[alloy]

Great to know!