Fails to parse string references to types about nexus-to-pothos-codemod

[villesau]

Nice, thanks for the first issue! Indeed, the codebase I've run this agains uses object references only so string references were not taken into account at all. I might look into it, but I can also help you forward in fixing this. The best way forward is to use https://astexplorer.net/ and debugger quite extensively. That's how I've usually worked with codemods.

Handing of args happens somewhere here:
https://github.com/villesau/nexus-to-pothos-codemod/blob/main/transform.ts#L53
It might require a new if-else branch here that handles the string references: https://github.com/villesau/nexus-to-pothos-codemod/blob/main/transform.ts#L63-L81

Handling types might be spread more widely and handled differently in queries and objects etc, but I think these places might be good places to start to dig into it:
https://github.com/villesau/nexus-to-pothos-codemod/blob/main/transform.ts#L85-L95
https://github.com/villesau/nexus-to-pothos-codemod/blob/main/transform.ts#L227-L239

Like said, the best way forward is to attach debugger and see what there is. You can make a test case with your stuff and run that with the debugger.

I believe this is fairly trivial to fix once the correct place to fix is found.

[awinograd]

Thanks for the info @villesau. I'm new to pothos so may be mistaken, but it doesn't seem like they have the concept of string references to non-scalar types. In that case what do you think the best path for implementation would be? Just keep the string an leave it to the user after the codemod to swap out to an objectRef?

[villesau]

Yeah looks like string references are not supported. We've always used object references instead so not entirely sure, but based on my quick test I didn't get it working. I see a few options here:

1. first migrate to object references in Nexus and then run the codemod
2. fix the codemod & fix the references after
3. make a version of the codemod that turns string references to object references. This removes one step and might be handy, but I would not merge it unless it's behind a flag as it is not guaranteed that the string reference has same name as the object reference.

In any case the migration is fairly safe since you probably already have the schema printed somewhere in which you can compare the end result to.

[awinograd]

@villesau I think (1) might be the best path forward. Doesn't seem like too heavy of a lift and probably makes most sense considering that's what pothos expects anyway. (2) would require the same amount of manual work after the fact anyway, so not sure it buys us much and just adds more code to deal with on your end.

Feel free to consider this closed if you'd like! Thanks again for talking through the issue

[villesau]

@awinograd actually I just realized that custom scalars can be defined as strings. For example:

builder.addScalarType('JSONObject', GraphQLJSONObject, {}); (like in the readme example: https://github.com/villesau/nexus-to-pothos-codemod )

and

      json: t.arg('json', {
        type: 'JSONObject'
      }),

It seems that object references cannot be. So if you have e.g User, you cannot:

      user: t.arg('user', {
        type: 'User'
      }),