Someone is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

CI failed but seems not my fault.

This is indeed something we plan to fix, but this PR attacks the problem at the wrong level—leaking the implementation of globby into context.go We're going to pull this behavior into the globby package itself. globby should be able to optimize the amount of IO it does based upon its inputs, the call site shouldn't need to know about the globby implementation details to optimize against invoking it.

We're going to pull this behavior into the globby package itself.

Well...Is the behavior(not glob match) correct if It's in the right position?

I can't say for sure how it is going to be implemented since globby is about to get a full rewrite. (You can see the tests being added so that we can make sure we don't break globby over in #1090.)

Without having attempted it, my current hypothesis is that doublestar.GlobWalk will successfully optimize away the non-globbing patterns without needing to optimize the call first from application code. (We're not using GlobWalk presently, we fs.Walk and then call doublestar.PatternMatch twice.)

I'm trying to avoid introducing branches in application code if the optimizations are already in place. And, if doublestar doesn't optimize for it, it's something we may attempt to push upstream.