My conclusion
This seems to be an issue with deep network of dependencies: globby -> fast-glob -> micromatch. At the top of the stack trace, fast-glob calls a function from micromatch:
const info = micromatch.scan(pattern, Object.assign(Object.assign({}, options), { parts: true }));
// See micromatch/picomatch#58 for more details
if (info.parts.length === 0) {
return [pattern];
}
If you console.log(info), it has no parts property:
{
prefix: '',
input: 'src/umd-exchange/gql/*.graphql',
base: 'src/umd-exchange/gql',
glob: '*.graphql',
negated: false,
isGlob: true
}
The micromatch version that causes the bug is 4.0.2.
The fast-glob version that causes the bug is 3.2.0.
The globby version that causes the bug is 11.0.0.
So basically, this problem happens when everything is on their latest version.
Describe the bug
$ graphql-codegen
✔ Parse configuration
❯ Generate outputs
❯ Generate src/umd-exchange/gql.ts
✔ Load GraphQL schemas
✖ Load GraphQL documents
→ Cannot read property 'length' of undefined
✖ src/umd-exchange/gql.ts
TypeError: Cannot read property 'length' of undefined
at Object.getPatternParts (<omitted>/node_modules/globby/node_modules/fast-glob/out/utils/p
attern.js:94:20)
...
To Reproduce
Steps to reproduce the behavior:
https://codesandbox.io/s/vibrant-fire-f0x5p
type Subscription {
newMessage(conversationId: Int!): String!
}
schema {
subscription: Subscription
}
subscription onNewMessage($id: Int!) {
newMessage(conversationId: $id)
}
codegen.yml config file:overwrite: true
generates:
src/umd-exchange/gql.ts:
schema: src/umd-exchange/schema.graphql
documents: src/umd-exchange/gql/*.graphql
plugins:
- typescript
- typescript-resolvers
- typescript-operators
- typescript-graphql-files-modules
Expected behavior
No error.
Environment:
"@graphql-codegen/cli": "1.12.2""@graphql-codegen/introspection": "1.12.2""@graphql-codegen/typescript": "1.12.2""@graphql-codegen/typescript-document-nodes": "1.12.2""@graphql-codegen/typescript-graphql-files-modules": "1.12.2""@graphql-codegen/typescript-resolvers": "1.12.1"Additional context
I tried locking fast-glob to 3.1.1:
"resolutions": {
"fast-glob": "3.1.1"
}
Error has gone.
Reported upstream: https://github.com/mrmlnc/fast-glob/issues/253
@anilanar Thank you. You saved me a lot of time
@anilanar Thank you for reporting and finding a workaround!
I tried to run the reproduction sandbox - but it seems to work, can you please verify that?
@anilanar thank you, you saved my day. For those who use npm, I found this plugin to use "resolutions" as workaround: https://www.npmjs.com/package/npm-force-resolutions
TL;DR
We are waiting for a fix by micromatch, then fast-glob and globby needs to release a new version too.
@dotansimha It's kind of hard to reproduce. I had to copy my own yarn.lock and then run yarn, which updates yarn.lock again.
The specific problem is described in https://github.com/micromatch/micromatch/issues/196 and in https://github.com/mrmlnc/fast-glob/issues/253. So the problem only happens if node_modules had a version of picomatch between 2.0.5 and 2.2.0 before installing a dependency that requires micromatch 4.0.2.
It seems like fast-glob solved it in v3.2.1. Keeping open until fully solved.
Thanks @anilanar
Most helpful comment
I tried locking
fast-globto3.1.1:Error has gone.