workspaces: ENOENT in lstat, no stack trace

[jdmarshall]

Node 8.9.4, yarn 1.8.0, using workspaces

Repeatable error of Error: ENOENT: no such file or directory, lstat for project/workspacedir/submodule/node_modules. The previous verbose log message is about creating symlinks for another directory, so I believe this is happening during the linking phase. Unfortunately Yarn seems to be eating the stack trace even in --verbose mode, so I don't know where the problem actually happens.

The first problem is that you're eating stack traces:

Trace:
Error: ENOENT: no such file or directory, lstat '.../project_name/workspaces/module_name/node_modules/'

The word trace has a very specific meaning, and this is not it. This is an error message. It doesn't tell me where the problem is which means I can't solve it on my own or file a PR.

I believe the workspace in question may have a strict subset of the dependencies of the parent module. Is it possible this is a corner case when 100% of the dependencies are satisfied by the parent? But if I manually create module_name/node_modules then the error is about no such file or directory for module_name/node_modules/mocha.

The second error might relate to #5827, since project_name/node_modules/.bin/mocha was linking into one of the workspace modules instead of using node_modules/mocha/bin, which also exists.

[conrad-vanl]

We're facing this issue... the error message goes away if we remove any nohoist params that we have in our package.json - either at the root level or in our sub modules.

[thymikee]

One of Jest PR has this issue: jestjs/jest#6871.
As @conrad-vanl already mentioned, removing nohoist also turned out to fix it, but wanted to leave a comment because it may serve as a repro (not quite minimal, but still).

[markdoliner]

I ran into this problem. I was never able to figure out where exactly it was coming from. It's definitely hard to debug without a stack trace. I think there's no stack trace because the error gets swallowed by a promise?

But I did manage to find a workaround. In my case I was specifying this in my create-react-app app's package.json file:

"nohoist": [
  '**',
  '**/**'
]

I changed it to:

"nohoist:": [
  'react-scripts',
  'react-scripts/**'
]

And that fixed the problem for me. I could imagine a similar fix working in the root package.json file, for those of you who specify nohoist there.

I don't understand yarn well enough to know why this works. I can speculate that maybe the old nohoist config was telling yarn to keep a separate copy of everything, including the local shared-utils package that's in my workspace, and maybe that doesn't work for local dependencies.

[elmpp]

I believe this is due to Yarn's zip archiving of packages, preventing stack traces being easily passable from Node. Yarn generates the errors as a result - https://github.com/yarnpkg/berry/blob/554257087edb4a103633e808253323fb9a21250d/packages/yarnpkg-fslib/sources/ZipFS.ts#L640

It'd be nice to include any available userland trace lines here because it really does cause a hard debugging problem