Getting "Workspaces can only be enabled in private projects" even for a private project

[kaiyoma]

I'm using yarn + lerna in a mono-repo, and today, after rebuilding my lockfile, I started seeing this warning from yarn:

[3/4] Linking dependencies...
warning Workspaces can only be enabled in private projects.

I'm not sure why I'm seeing this because I have this in my package.json:

  "private": true,

Seems like a bug in yarn?

Node 14.15.0
yarn 1.22.5
lerna 3.22.1

[gabegorelick]

I'm seeing this warning in a public project that does not use workspaces.

[rally25rs]

Could you provide a minimal package.json to reproduce the issue?

[IanMayo]

Possible duplicate of: webpack/webpack-cli#479

[bkglobal]

In package.json add the directory in workspace like

"workspaces": [
      "app/*"
]

[gabegorelick]

Possible duplicate of: webpack/webpack-cli#479

In my case, the issue is indeed caused by a dep that has workspaces set (although not webpack-cli in my case).

Seems like yarn should either tell you the offending package, or just not warn at all if a dep erroneously has workspaces set.

[kennie-larkson]

I am having this same warning in a project that does not use workspaces upon yarn add moment and I have ‘private’: true in package.json

[eps1lon]

At this point it shouldn't warn about this in dependencies at all. The dependencies might be using a package manager that uses that field differently. For example, in yarn v2 using workspaces in a published package is perfectly fine:

Worktrees used to be required to be private (ie list "private": true in their package.json). This requirement got removed with the 2.0 release in order to help standalone projects to progressively adopt workspaces (for example by listing their documentation website as a separate workspace).

-- https://yarnpkg.com/features/workspaces#how-to-declare-a-worktree

For us, we get the warning since we have react-redux installed. But react-redux is setup correctly from their viewpoint. So the warning is not actionable.

[kaiyoma]

See also reduxjs/react-redux#1815

[mjstelly]

For us, we get the warning since we have react-redux installed. But react-redux is setup correctly from their viewpoint. So the warning is not actionable.

So, do you mean that it's likely a false positive? I'm new to workspaces and my current project uses them with Yarn Classic. But I question whether they have been set up correctly due to other problems I found. I can't determine if this warning arises from something I did, or the existing project itself. It actually displays 3 times

Error running 'yarn install (if yarn is installed)': warning Workspaces can only be enabled in private projects.
Error running 'yarn install (if yarn is installed)': warning Workspaces can only be enabled in private projects.
Error running 'yarn install (if yarn is installed)': warning Workspaces can only be enabled in private projects.

[benquarmby]

NPM says hello and a friendly "up yours" to the only-private-packages-have-workspaces rule 👋

[ale917k]

It's been a year and a half since raised; Has anything been done or discussed about this? Can the warnings at least be omitted when flagged on dependencies? Bit annoying to have all these around..

[nhhockeyplayer]

its gotten worse on node v18
can no longer install even if you toggle their property on or off

meanstack02@admin meanstacknh % yarn install
yarn install v1.22.19
error Workspaces can only be enabled in private projects.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

build is now blocked
no wait its now working after waiting 5mins... must be all the arcane hidden ".cache" folders dispersed everywhere in $home and beneath node_modules

these institutions are in over their head and the frustration is a group failure altogether mismanaged
it all started with npmjs.org which is still collecting credit card subscriptions and nothing works like a real software project should

hopefully microsoft will fix everything

[gduliscouet-ubitransport]

@rally25rs @merceyz Here is a minimal reproduction package.json of the issue (just installing semantic-release revealed this unwanted warning):

{
  "name": "yarn-warning-repro",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "private": true,
  "dependencies": {
    "semantic-release": "^19.0.3"
  }
}

yarn version 1.22.19
node version 16.14.0

A repository of the reproduction: https://github.com/gduliscouet-ubitransport/yarn-warning-repro

[rally25rs]

thanks for the repro case @gduliscouet-ubitransport

It looks like one of the transitive deps is npm

semantic-release > @semantic-release/npm > npm

The npm package's package.json indicates it is a workspace

{
  "version": "8.17.0",
  "name": "npm",
  "description": "a package manager for JavaScript",
  "workspaces": [
    "docs",
    "smoke-tests",
    "workspaces/*"
  ],

which is what is leading to this warning.

Since this is just a warning I think it can be ignored; the npm library still does get installed into node_modules

[guillaumeduliscouet]

Thank you @rally25rs for analysing this,
Can we close this issue/subject with a clear conclusion ? I see 2 possibilities:

1. This "workspaces should be private" rule is a standard for package managers. They should all warn (or error) if the project (or one of its dependencies) is breaking the rule.

In this case I'll open an issue on the npm repo and any other repo breaking the rule and we can close this one.

2. The rule is not standard, only yarn is applying it.

In this case yarn should not warn for dependencies breaking the rule since they may use another package manager.

I agree that it is only a warning and it can be ignored, but some warnings need to be addressed and this one is just creating noise. It is encouraging devs to ignore every warnings, making warnings useless

[dylang]

This warning is typically for the a third party dependency or dependency of a dependency getting installed.

It's not likely useful for developer running the install.

This is made extra confusing by not showing the name of the module the warning is for.

My opinion is that this warning should only be displayed when publishing if a published package has workspaces in the package.json. It should not be shown at install. At this point it's too late and has no effect on the install so it doesn't matter.

The only time it should be shown at install time is if this problem is with one of the packages in the workspace. And if that's the case, it should say which package that is.

[kiranojhanp]

In my case, I was trying yarn add but our monorepo was using pnpm. Silly mistake in my part.

[Tofandel]

The piece of code throwing the warning

yarn/src/config.js

Lines 873 to 876 in 3119382

	if (wsCopy.packages && wsCopy.packages.length > 0 && !manifest.private) {
	errors.push(this.reporter.lang('workspacesRequirePrivateProjects'));
	wsCopy = undefined;
	}

[ijemmao]

Is there any update on this issue? I'm experiencing this issue in my public repo: https://github.com/nkowaokwu/igbo_api/actions/runs/4455179532/jobs/7824826839?pr=576

[AnonymousX86]

It is possible to explicitly disable it ¹ in .yarnrc file. ²

Footnotes

1. https://classic.yarnpkg.com/lang/en/docs/workspaces/#toc-tips-tricks ↩

2. https://classic.yarnpkg.com/lang/en/docs/yarnrc/ ↩

[nopeless]

Is it not possible to inform the developer which project is actually offending? i.e. the workspace project that does not have "private": true? This seems like a useful feature

[alfaproject]

I guess no hope for this?

[natesire]

error Workspaces can only be enabled in private projects.

It's related to the built-in @npmcli dependencies using workspaces. I have been debugging the other side of the issue from the npm side. I had to switch to yarn just to work around things. NPM CLI is broken on windows for Node 16.14+ because of NPM.

Then I saw all of these warnings pop up related to workspaces when running yarn.

npm/cli#6601

[markedwards]

It is possible to explicitly disable it 1 in .yarnrc file. 2

Perhaps stating the obvious, but this doesn't apply if your project uses workspaces. In my case, my project uses workspaces correctly, but some dependency violates the rule, hence the warning. So I'm stuck until this is silenced.

[rmclaughlin-nelnet]

We are in the process of converting from NPM to Yarn, because NPM nohoist options suck, and we ran into this. What is the logic behind restricting workspaces to only private projects?

[ckhatton-transreport]

After 1.5yrs of this ticket being open, this comment above seems the only option 😓
#8580 (comment)

[rally25rs]

@ckhatton-transreport

After 1.5yrs of this ticket being open, this comment above seems the only option

Yarn classic / v1 has not been in active feature development for a couple years. Major version 4 is close to being released.
Classic/v1 only receives critical security fixes and bug fixes that would prevent it from working.

While it is an admittedly confusing message, Seeing a warning does not prevent anyone from continuing to use yarn.

---

@rmclaughlin-nelnet

What is the logic behind restricting workspaces to only private projects?

I didn't write that feature initially, but I believe the thought behind "workspaces" was that they are a collection of deploy-able npm packages (each package in the workspace would be npm published as a library), but they themselves are not supposed to be published libraries. I suspect the thinking behind the private: true check was that having it a private package would help prevent the workspace root from being npm published as a dependency.

---

I'm going to mark this issue as closed because

• yarn v1 is unlikely to release a fix for this non-breaking issue
• the message is a warning that can be suppressed in .yarnrc

I'd also like to take this moment to encourage folks to upgrade to yarn modern where possible.

[avarun42]

Since this is just a warning I think it can be ignored; the npm library still does get installed into node_modules

This is useless and unproductive. Of course a warning can be ignored, but if a warning is not providing any actionable information whatsoever (you would agree that a yarn user using npm as a transitive dependency is not making a mistake, correct?) then that warning should not exist. Especially since the warning currently doesn't even state which package it's referring to.

I would consider this a bug in yarn v1.

I'm going to mark this issue as closed because [...] the message is a warning that can be suppressed in .yarnrc

Not actually true. The mentioned .yarnrc config turns off workspaces entirely. This is obviously not a solution that works if you're actually using workspaces. However, in that situation the warning message being thrown is both useless and a red herring. You can be inside a private project with workspaces enabled and end up seeing the message due to a transitive dependency.

---

Keep in mind this problem doesn't just affect users of yarn once. It affects every single installer of a project that's using yarn, who may wonder why they're seeing a warning only to end up on this thread that's telling them to ignore it — by definition a waste of time and productivity for everybody that could be solved by simply not showing a useless warning.

[jonkoops]

This bug should be re-opened and fixed, it is an issue in Yarn v1, since it is still the default, even when initializing a new project. This is actively causing issues for users of classnames (JedWatson/classnames#329 (comment)).

[malininss]

Why is there no reaction if this is obviously a bug? I use workspaces in my project and can't turn them off in .yarnrc

[darklight9811]

Also think this still a bug that should be fixed

[mjugger]

this is not even a warning it is throwing an error for me and preventing the project from being installed. is there a way to completely bypass this?

[fulldecent]

Here is the solution to this issue (not a workaround). The issue should stay closed because it is solved.

tl;dr You are running and old version of Yarn. And when you think you are upgrading it you are not.

---

Root cause

You are running an old version of Yarn. And when you think you are upgrading Yarn, you are not.

Proof:

yarn --version

Compare to actual current Yarn releases.

Things that don't work ❌

Don't do these things. Intuitively they look like they will work but actually they do nothing.

• brew upgrade yarn

  This installs an old version. No deprecation warning. No hints. Just wrong output.

  You can see the formula at https://github.com/Homebrew/homebrew-core/blob/d01418781a024b63d9ba9e1299d7f1edf703558b/Formula/y/yarn.rb which is wrong. It mentions version 2 as the implied latest. But actually the latest is currently 4. PR sent.

• Add your notes for other package managers here…

Solution

Uninstall Yarn on your system if you installed it using any non-preferred (even retroactively non-preferred) ways.

brew uninstall yarn

Then install the preferred way. (Here is how I prefer, there are others.)

brew install nvm
nvm install --lts --reinstall-packages-from=current # If you don't use that second flag you get old version
nvm use --lts

Then install yarn

corepack enable # You already have this command installed when you installed Node.js

Then delete your .lock file which may be preventing upgrades

rm yarn.lock

Now you can use yarn

yarn install
yarn set version stable # This will update your package.json to add a $.packageManager entry

Notice how everything looks different? You are on the new version now. And the warning is gone.

---

Follow on work

Please feel free to ignore any of this. Good vibes only.

Here's how I think the world can be a better place:

• Brew should not imply that the latest version of yarn is 2.x PR sent
• Yarn project should publish a page https://yarnpkg.com/getting-started/upgrade that lists all the error messages you could get from running an old version of Yarn, then all the steps above on how to upgrade, then we can all link to that page, yay!
• Yarn project should be more agressive on ending version support. Currently the Yarn project actively maintains over 100 versions of the product. Yes, if one version of Yarn installs another version of Yarn and does not warn you to upgrade… that counts as actively supported.
• Yarn project should make one more derprecation release for each major branch, because SemVer.
• Brew should publish that new 1.x.y+1 release. Now everybody using yarn installed by Brew will get the upgrade message.

[markedwards]

@fulldecent this issue is not about yarn berry, its about yarn v1. Please see the above discussion.

[benquarmby]

Yarn Berry, the Node package manager module system replacement nobody asked for.

Another alternative is switching to pnpm, which just keeps delivering on the original promise of Yarn 1.x; a faster more stable NPM. None of these package managers are perfect. PNPM has its own issues just like yarn 1.x, but it's actively maintained, and this particular warning does not happen. pnpm import ./yarn.lock is a great place to start.

[Tofandel]

It's also not just brew, if v1 really should not be installed then it shouldn't be the default in the distros package managers. Right now apt install yarn on any distro will get you v1 by default. Same with npm npm install --global yarn will get you v1

sudo yarn self-update ? This will do nothing https://classic.yarnpkg.com/lang/en/docs/cli/self-update/

curl --compressed -o- -L https://yarnpkg.com/install.sh | bash will install v1

If they really want people to upgrade to v4 then it shouldn't be so painfully hard to do so

Instead yarn v4 has to be installed on top of v1 for any project that you run, it cannot be installed globally AFAIK

Yarn berry is in a completely different project so the releases are not tracked in this one and that's probably because it's now a completely different package manager

So yeah do yourself a favor and switch back to npm or pnpm which have come a long long way since then compared to yarn