berry: [Bug] Yarn shell throws errors about Glob patterns

  • I’d be willing to implement a fix

Describe the bug

Next.js uses so format of files: [id].jsx, [...subpaths].jsx. When I execute this command in the scripts section of package.json:

{
  "scripts": {
    "copyfile": "shx cp [id].jsx somefolder/[id].jsx",
  }
}

Yarn throws this error:

Internal Error: No file matches found: ".../[id].jsx". Note: Glob patterns currently only support files that exist on the filesystem (Help Wanted)
    at interpolateArguments (/Users/aleksandr/WebProjects/testproject/.yarn/releases/yarn-sources.cjs:47916:46)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async executeCommandChain (/Users/aleksandr/WebProjects/testproject/.yarn/releases/yarn-sources.cjs:48064:24)
    at async executeCommandLine (/Users/aleksandr/WebProjects/testproject/.yarn/releases/yarn-sources.cjs:48148:26)
    at async executeShellLine (/Users/aleksandr/WebProjects/testproject/.yarn/releases/yarn-sources.cjs:48189:25)
    at async execute (/Users/aleksandr/WebProjects/testproject/.yarn/releases/yarn-sources.cjs:48364:10)
    at async realExecutor (/Users/aleksandr/WebProjects/testproject/.yarn/releases/yarn-sources.cjs:47310:14)
    at async /Users/aleksandr/WebProjects/testproject/.yarn/releases/yarn-sources.cjs:47330:12
    at async NodeFS.mktempPromise (/Users/aleksandr/WebProjects/testproject/.yarn/releases/yarn-sources.cjs:28705:18)
    at async Module.executePackageScript (/Users/aleksandr/WebProjects/testproject/.yarn/releases/yarn-sources.cjs:47295:10)

I only find solution to replace the filename with ?id?.jsx.

  1. I was had to extract this command from the scripts section into a bash script
{
  "scripts": {
    "gcp-build": "find build -name '\\[@@@*' -exec bash -c 'mv \"$1\" \"${1/@@@/...}\"' -- \\{\\} \\;"
  }
}

because it thrown this error:

Internal Error: No file matches found: "\{\}". Note: Glob patterns currently only support files that exist on the filesystem (Help Wanted)

In the bash script it looks as:

find build -name '\[@@@*' -exec bash -c 'mv "$1" "${1/@@@/...}"' -- {} \;

About this issue

  • Original URL
  • State: open
  • Created 4 years ago
  • Reactions: 4
  • Comments: 19 (8 by maintainers)

Commits related to this issue

Most upvoted comments

You need to quote it to avoid glob expansion

{
  "scripts": {
    "foo": "DEBUG='beemo:*' node -p process.env.DEBUG"
  }
}

I had understood that comment as I needed the DEBUG= part. But it was just

"clean": "rimraf '*.tsbuildinfo'"

Much obliged!

You need to quote it to avoid glob expansion

{
  "scripts": {
    "foo": "DEBUG='beemo:*' node -p process.env.DEBUG"
  }
}

I thought it was problem of zsh until I read this reply. Thank you!

Your case is expected, @royra. Use || true to silence the error if matching nothing is the intended behaviour.

May I ask what is the reasoning behind the new behavior - parsing the command and expanding globs, instead of leaving it to the shell?

Yarn 2 implements a basic shell in order to make most commands portable across all environments, Linux and Windows alike. As for a lot of things we tend to prefer being strict and failing early, hence why we upgrade into errors glob patterns that have no match (instead of passing them untransformed to the underlying tool, which could have dire consequences).

Use || true to silence the error if matching nothing is the intended behaviour.

In case this helps anyone, appending || true to the command did solve our problem, by preventing the resulting “no matches found” error from stopping the execution of subsequent commands, however it does not “silence” the error. “No matches found” still shows up in the console. This is fine for our purposes, but it was causing me a bit of confusion as to whether the || true was working as intended.

Adding another use case which is broken on our repo (works on yarn v1).

package.json scripts:

{
  "clean": "rm -rf ./dist .*.cache"
}

If there are no files matching .*.cache, it throws:

No file matches found: ".*.cache". Note: Glob patterns currently only support files that exist on the filesystem (Help Wanted)
    at O (/Users/roy/salto_private/.yarn/releases/yarn-2.3.3.cjs:2:519009)

Also happens with master (which now includes #1790).

May I ask what is the reasoning behind the new behavior - parsing the command and expanding globs, instead of leaving it to the shell?