https://www.prisma.io/ logo
Join Slack
Powered by
Ouch; I’m actually unable to find any way to attac...
# prisma-whats-new
p
Ouch; I’m actually unable to find any way to attach my WebStorm project to the debug session created by launching 
yarn debug
on my Prisma project!
h

https://i.imgur.com/q7eCKyU.png▾

that's how you do it
I generally use the chrome debugger because the built in one in webstorm is underwhelming and buggy for js
p
Thank you, I did indeed try this but ended up with an empty Console window after clicking debug!
Right, so I guess WebStorm is getting a 
Connection refused: localhost/127.0.0.1:9229
error
…which makes sense since the server is indeed giving an error when I run `yarn start`… but not when I run 
yarn debug
! What I’m trying to do is hit the breakpoint before it fails to start…
h
change it to 
--inspect-brk
in the script
then it will wait until you attach a debugger before it executes anything

https://i.imgur.com/8vCF9XC.png▾

you can also set up a config like this
p
I tried that as well actually, but it’s still not attaching… is 127.0.0.1:9229 correct though? I don’t know where that comes from
l
Try just --inspect
h
working directory should be the folder .env is in
l
Is the console printing out that the port is open?
h
after it starts it should show 
Debugger listening on <ws://127.0.0.1:9229/0ab18b05-e447-4ee5-a355-a27e6fa65953>
p
No! The console is only printing this out:
Copy code
→ yarn debug
yarn run v1.5.1
$ dotenv -- nodemon -e ts,graphql -x ts-node --inspect-brk src/index.ts
[nodemon] 1.17.2
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.*
[nodemon] starting `ts-node --inspect-brk src/index.ts`
h
that's all?
p
Yup
h
oh you're using ts-node
p
Oh I’m sorry I didn’t specify this, yes.
h
wait did it print anything with just 
--inspect
?
p
No, the same message:
Copy code
→ yarn debug
yarn run v1.5.1
$ dotenv -- nodemon -e ts,graphql -x ts-node --inspect src/index.ts
[nodemon] 1.17.2
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.*
[nodemon] starting `ts-node --inspect src/index.ts`
h
ah ok
p
I believe the server is simply refusing to start with 
directiveResolvers
in there
l
Take them out and try
h
can you try changing the part after -x to 
node --inspect-brk -r dotenv/config -r ts-node/register src/index.ts
?
p
When I commented 
directiveResolvers
out, it worked
l
I suspect something changed with GraphQL-Tools
p
Though the statement 
Server is running on <http://localhost:4000>
only appears when I run 
yarn dev
and never when I run 
yarn debug
@lawjolla yes I believe so too
@harmony where do you want me to change the part after -x, in the WebStorm configuration?
h
in the debug script
package.json
p
Yup, that displayed
Copy code
→ yarn debug
yarn run v1.5.1
$ dotenv -- nodemon -e ts,graphql -x node --inspect-brk -r dotenv/config -r ts-node/register src/index.ts
[nodemon] 1.17.2
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.*
[nodemon] starting `node --inspect-brk -r dotenv/config -r ts-node/register src/index.ts`
Debugger listening on <ws://127.0.0.1:9229/4b0cecbd-4e60-4905-9dcf-12504daf95ab>
For help see <https://nodejs.org/en/docs/inspector>
Which means debugger is at least listening now… however, that was with 
directiveResolvers
still out! Let me try and uncomment it… the idea is to try and reach the breakpoint before the server starts.
l
Exactly
Which version of graphql tools are you/yoga using?
h
yes with inspect-brk it will wait until you attach the debugger and then run
p
"graphql-yoga": "^1.6.0",
h
so next you'll want to attach the debugger which will probably hit the breakpoint
p
I attached it… but it didn’t lol
l
What version of graphql-tools
p
I’m not including 
graphql-tools
explicitly 😯
I just added it as a dependency, 
"graphql-tools": "^2.23.0"
But that produced the same 
Error: SchemaDirectiveVisitor for @isAuthenticated must implement visitQuery method
l
That's how the debugger attaches. PhpStorm does something that causes the screen recording app to stop when the debugger breakpoint hits
grapql-tools is a yoga dependency. That's the one that matters
Which version is it running?
p
How do I find that out?
l
npm ls graphql-tools
p
So the breakpoint is being hit, you’re right, it’s just not producing much…
Copy code
→ npm ls graphql-tools
mblt-gql@2.0.0 /Users/Sammy/Projects/mblt-gql
├── graphql-tools@2.23.0 
├─┬ graphql-yoga@1.6.0
│ └── graphql-tools@2.23.0  deduped
└─┬ prisma-binding@1.5.16
  ├─┬ graphql-binding@1.2.5
  │ └── graphql-tools@2.21.0 
  └── graphql-tools@2.21.0
Well, if I step over enough times, I get the same error… I’m going to try and step into directiveResolvers const to see…
l
Yeah, so there's your answer. I'm sure there's a better way to do this, but for a quick hack, go into yoga's package file and pin graphql-tools to 2.22.0, then npm install
See if it goes away
They don't have a changelog for 2.23. Helpful
p
But if it were that, how come when I downgraded to v 1.5.2 the same error persisted?
l
Probably an NPM lock issue
p
There you go, I’m glad I’m not crazy
Did you read the workaround though?
l
Yes. That's not a breaking change in the sense of they're enforcing the directive definition
p
That workaround did fix it indeed.
I just don’t understand what 
FIELD_DEFINITION
is relative to 
QUERY | MUTATION
Thank you both very much in any case.
l
You're applying the directive to the field definition, not the query or mutation type
You weren't able to apply directives to types. I suspect there's an API change coming and this is part of the change
directive @auth on FIELD | FIELD_DEFINITION
When something doesn't make sense, visit our friend the spec. http://facebook.github.io/graphql/draft/#sec-Type-System.Directives
😍 1
Here’s the news! Great stuff for GraphQL from Apollo (GraphQL-yoga 1.6 uses the latest GraphQL-tools, so get busy!) https://dev-blog.apollodata.com/reusable-graphql-schema-directives-131fb3a177d1
p
👍
2 Views
Open in Slack
PreviousNext
Powered by