Discussion about developer experience

[kandros]

Nexus uses a particular approach to deal with typechecking, that involve generation of typings types files from "runtime defined objects" that extend a global "object type" that nexus itself uses to typecheck other types.

This is meant as a discussion to find problems related to developer experience and a possible solution to address them.

[kandros]

a personal scenario:
server is crashed or not running and the update of generated typings files is no longer happening, so the typechecking 'feels' broken

[tgriesser]

a personal scenario:
server is crashed or not running and the update of generated typings files is no longer happening, so the typechecking 'feels' broken

Yes, I agree this should be better dealt with. Possibly with an editor extension that checks whether the Nexus server is running?

Ping @Weakky to see if you've had any thoughts around this with yoga2.

[Weakky]

Had a similar issue on nexus-prisma recently: graphql-nexus/nexus-prisma#183 (comment)

TLDR: The user is complaining that he's forced to start his server before being able to build it.

• As yoga2 has a build command in its CLI, one thing I'm planning to do is to programmatically run the type generation before building the project to make sure they're up-to-date.

• Another potential fix to better the experience is that TS proposal: Proposal: new "invalid" type to indicate custom invalid states microsoft/TypeScript#23689

  If I do understand it properly, we could use invalid('Please, start your server to update generated types') instead of all these any fallbacks that we use in the conditional types to not break the app if types aren't there.

• An extension could also be an option, we could also pack it with the SDL comments we've been talking about Generate SDL comments on top of nexus calls prisma-labs/yoga2#33 since a long time, instead of messing with people's file as we're planning to do. I'm just a bit concerned that people will complain they'll need an extension just to have a good experience with the library

Apart from these hints, I could not come up with a better solution til now 😕

[tgriesser]

TLDR: The user is complaining that he's forced to start his server before being able to build it.

I recommend running your normal development server in transpile-only mode via the -T flag to ts-node or similar (isolatedModules option, etc.).

Then have a separate process which actually is checking the types. Usually I'll do this as part of CI rather than locally, but you could come up with a script to do this locally as well. Maybe it's worth setting up some gulp scripts that set this sort of thing up out of the box?

[kandros]

using --transpile-only is indeed very useful.

probably most of the possible solutions make more sense to be in yoga2 given how invasive they can be like inserting inline comments when some common errors are found using AST manipulation so that it can be editor agnostic

[kandros]

During today's OpenSourceSaturday meetup in Milan, when demoing for nexus to some persons I (once again) felt in subtle DX issues that hit me in the face all the time :D

• Forgetting to run Server (thus generating new typings)
• Forgetting to add name parameter in objectType resulting in a not-so-friendly error message

I'm experimenting is prevent these and other minor problems related to very hard to debug typings error with an eslint plugin https://github.com/kandros/eslint-plugin-nexus.

I'm very far from proficient in eslint rules development especially related to TS parser, if someone could guide me in the right direction I would love to dedicate some time in making nexus development experience easier in the day-by-day (some TS errors are just too much to deal with after lunch 😁 when there are 10+ generics involved)

https://twitter.com/kandros5591/status/1112014449924337664

[jasonkuhrt]

Related prisma/prisma-examples#867 (comment)

I've created scope/workflow to track this theme.

Will also reference out of band related issues here, one: https://prisma.slack.com/archives/CKQTGR6T0/p1570915353062700

[jasonkuhrt]

• https://prisma.slack.com/archives/CKQTGR6T0/p1571714715173100
• https://prisma.slack.com/archives/CKQTGR6T0/p1571664108151200

[jasonkuhrt]

Another prisma-labs/graphql-framework-experiment#278

[jasonkuhrt]

I would love to dedicate some time in making nexus development experience easier in the day-by-day

Hey @kandros you may be interested in prisma-labs/team#5 where we're building up an epic to tackle a large amount of issues around nexus workflow.

[thehappycoder]

I am currently trialing a workflow when I use vscode and 2 nodemon processes:

1. Only runs a script that generates types (runs via ts-node)
2. Doesn't generate the types and runs the api server. Transpiles the project using tsc and then runs build/index.js. If it's too fast to start, I may add a sleep so that 1st process has an opportunity to finish.

So far so good! When I make changes in vscode, types get generated, vscode picks the changes up and the api server restarts.

[jasonkuhrt]

@thehappycoder you might be interested to know that we've taken a massive plunge against this theme of this issue over the past few months. Still emerging from the shadows. You can check it out at https://nexus-future.now.sh/.

Update https://nexusjs.org

[gustawdaniel]

I propose to invest in docs of prisma nexus. More examples with both crud and totally custom mutations, queries and subscriptions.

More info about:

• what is not implemented and will be not implemented
• what is not implemented but planned
• about best practices and comparison of conventions

I see a lot of examples with small differences in notation and no discussion about comparison of them.

[jasonkuhrt]

Oopen for a long time. Many new issues came out of this. It has done its job. New issues always welcome ✌️