berry: The nearest package directory doesn't seem to be part of the project

The error happens when you have a yarn.lock (or package.json) file higher up in the filetree, at that point Yarn thinks you’re in a workspace you haven’t declared and throws.

Maybe clearer expression of my idea is: Yarn 2 tries to exercise control outside of the current project upwards, without boundaries, I think it is not right. Yarn should exercise control inside project boundaries and it should not bother Yarn what is upwards in directory hierarchy, if there is yarn.lock, package.json or anything else upwards in the directory hierarchy. In order to exercise control within project boundaries Yarn should not miss real project boundary and go upwards past it, how to do it right is a separate question.

The error happens when you have a yarn.lock (or package.json) file higher up in the filetree

Well I’ll be blowed! It was moaning about my home directory which to my knowledge didn’t have a yarn.lock in, but I just checked and there was a stray one there for some unknown reason 😅

I do wonder if there is a way to make this all a bit clearer. If nothing else, at least this issue is here for others to stumble across if they face the same error I guess.

I’m not sure we can make that clearer though … we already say what’s the problem, usually confusion only arise when users don’t actually trust the message and think it’s a bug 🤔

@arcanis To be honest I think this behaviour is part of bad UX. I think it’s pretty uncommon for commands to search for themselves up the directory tree for files to determine if the current directory is a workspace or a root-dir. That’s confusing to people. Better here would be to chose a good standard value. And I think it would be better to assume that the current directory is the always the root and if I want to change that behaviour let me use a flag like --workspace to actively search up the directory tree. And the error message should be also more clear, imho.

This was my thought process with the current bullets:

• If the project directory is right, it might be that you forgot to list as a workspace.

The project directory is right, maybe if I try adding "." as a workspace in package.json it will fix it? … Nope.

• If it isn’t, it’s likely because you have a yarn.lock or package.json file there

Hmm, I don’t have a yarn.lock in my monorepo root because I deleted it before running yarn and of course I have a package.json there, it’s a workspace… I’m not sure what this bullet is expecting.

Thanks, that’s helpful! So this is what we printed:

The nearest package directory (/home/user/project) doesn't seem to be part of the project declared in /home/project.

- If the project directory is right, it might be that you forgot to list my-project as a workspace.
- If it isn't, it's likely because you have a yarn.lock or package.json file there, confusing the project root detection.

I think the key point from your message is that the project directory wasn’t right. The error referenced /home/project as project directory, with /home/user/project being the package directory. However I can see that being confusing, the nuance is fairly subtle when you just want to use a random project.

Perhaps the following (plus colors, etc) would be clearer?

The nearest package directory (/home/user/my-project) doesn't seem to be part of what seems to be the project root in /home/project.

- If /home/project is the root of your project, it might be that you forgot to list my-project as a workspace.
- If it isn't, it's likely because you have a yarn.lock or package.json file there, confusing the project root detection.

We do have the option of ignoring the home directory and never use it as a project root

I’m not sure blocking it altogether in findProjectCwd is a good idea since it’s called before each command, but we can at least check that before throwing the error, to make it even more to the point.

The v1 had no linker concept, and special-casing node_modules folders is exactly the kind of special case I want to avoid. The problem here is the unexpected lockfile in the home directory (and in some level the error clarity), not the detection.

The detection is a problem. It is not the only complaint, we see them again and again. And there were no such complaints for v1. No matter how well the error message will be done, the problem will not be solved, because it is not in the error message.

Because then packages installed in the n_m folders would have no way to be tracked back to the original project, since they necessarily wouldnt’t be part of the workspaces field. Workarounding that would require special cases, and I want to avoid that.

Which “special” cases? It was not a problem in v1, was it? The packages in the n_m folders are in n_m folders, we can detect that and take into account.