Wrong dependency version for picomatch

[anilanar]

micromatch has a dependency of picomatch@^2.0.5.

Using the below code snippet with various matching picomatch versions:

const micromatch = require('micromatch');

console.log('Has parts?', micromatch.scan('*.js', { parts: true }).parts !== undefined);

Results:

// picomatch@2.0.5
false

// picomatch@2.0.6
false

// ...everything in between...
false

// picomatch@2.2.0
true

So, shouldn't the dependency be picomatch@^2.2.0?

Regression downstream:

mrmlnc/fast-glob#253

Or is parts a private API of micromatch?

[jonschlinkert]

Only create one issue, on one repository.

[anilanar]

And which repository do you think is a better fit for this?

[jonschlinkert]

And which repository do you think is a better fit for this?

I'm really not sure, but it seems like fast-glob is a good start, since the breakage is happening there. We all collaborate often, and I'd be happy to help debug.

FWIW, when you create the same issue on multiple repositories (specifically, before figuring out exactly what the issue is), you end up creating a scenario where no one knows who is tackling the issue or spending there time debugging, and no one wants to duplicate efforts.

[anilanar]

I understand your initial reaction, creating issues in multiple repos probably isn't very helpful in most circumstances. However, I think I've done my homework good and every repo is aware of what might be going wrong and who is responsible for it.

I've come here from graphql-code-generator -> globby -> fast-glob -> micromatch -> picomatch, debugging every layer and interaction between deps with multiple versions, finally nailed down the exact problem. You see, the problem doesn't occur with every version combination. It's basically about luck how yarn/npm hoists dependencies which depends on a lot of factors such as the state of package-lock or yarn-lock before adding a dependency that causes the error.

Reported to each repo with the source of regression; so that users/library maintainers using any of them don't spend as much time as I did.

Just glad that micromatch and fast-glob can sort this out very soon.

[jonschlinkert]

Reported to each repo with the source of regression; so that users/library maintainers using any of them don't spend as much time as I did.

Fair enough, that makes sense, and given the amount of time and attention you've given this, it seems I was hasty in my assumptions. I appreciate it, thank you.

[danez]

Release in 4.0.3