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: https://github.com/webpack/webpack-cli/issues/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 https://github.com/reduxjs/react-redux/issues/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

https://github.com/yarnpkg/yarn/blob/3119382885ea373d3c13d6a846de743eca8c914b/src/config.js#L873-L876

[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 ^1 in .yarnrc file. ^2

[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.

https://github.com/npm/cli/pull/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 😓 https://github.com/yarnpkg/yarn/issues/8580#issuecomment-1483520779

[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 (https://github.com/JedWatson/classnames/pull/329#issuecomment-1871740033).

[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