Skip to content
This repository has been archived by the owner on Apr 23, 2020. It is now read-only.

Traps & Friction Points #5

Open
22 tasks
jasonkuhrt opened this issue Oct 28, 2019 · 6 comments
Open
22 tasks

Traps & Friction Points #5

jasonkuhrt opened this issue Oct 28, 2019 · 6 comments
Labels
needs/investigation Possibly an issue, needs more analysis/research scope/workflow type/epic

Comments

@jasonkuhrt
Copy link
Member

jasonkuhrt commented Oct 28, 2019

We have consolidated the issues in this epic to an organized notion table. It is public.

When this issue is resolved we should be able to mark the following as resolved too:

@jasonkuhrt jasonkuhrt added type/epic scope/workflow needs/investigation Possibly an issue, needs more analysis/research labels Oct 28, 2019
@Weakky

This comment has been minimized.

@jasonkuhrt

This comment has been minimized.

@jasonkuhrt
Copy link
Member Author

jasonkuhrt commented Oct 28, 2019

@Weakky

🔵 Forgetting to run Server (thus generating new typings)
prisma-labs/graphql-framework-experiment#77 (comment)
💡Have a separate process always generating typegen

What does that solution mean/how could it help exactly?

🔵 No type-checking after cloning a repo
💡 Use postInstall npm hook to run nexus typegen

The best we could do with that solution is for it to be a pattern we suggest right? Since it would be app-level.

Cons: Less composable. We already have composability issues with t.field

We could allow the object version too, thus being backwards compatible. And that is nicer for machine use-cases as we identified the other night with t.field.

🔴 Runtime error prevents typegen from being re-run, thus making the typechecking desync/broken

How could this be fixed, though?

@Weakky
Copy link

Weakky commented Oct 29, 2019

What does that solution mean/how could it help exactly?

We could, for instance, have a VSC plugin running the typegen in the background, so that it's independent of the runtime.

The best we could do with that solution is for it to be a pattern we suggest right? Since it would be app-level.

Yes. "Encoding" that pattern in all examples + documenting it might be the best solution here

We could allow the object version too, thus being backward compatible. And that is nicer for machine use-cases as we identified the other night with t.field.

Still wondering whether it's a good idea to have two APIs to achieve the same thing. Might be confusing for users

How could this be fixed, though?

I don't think we can, hence why I labeled it as 🔴 (Trap)

@jasonkuhrt
Copy link
Member Author

More since here graphql-nexus/nexus-plugin-prisma#523

@ujwal-setlur
Copy link

Would love a VSC plugin to generate types

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
needs/investigation Possibly an issue, needs more analysis/research scope/workflow type/epic
Projects
None yet
Development

No branches or pull requests

3 participants