CODEWITHSUNDEEP
node.jsnpm
mikemaccana
mikemaccana

Reputation: 123148

npm workspaces "WARN: some-package-name in filter set, but no workspace folder present"

I have a repo with many npm packages inside, using npm workspaces

The top-level package.json contains the line:

  "workspaces": [
    "*"
  ]

When I run npm i -ws or other npm commands, I receive the warning:

WARN: some-package-name in filter set, but no workspace folder present

I'm not quite sure what the message means - I think the 'filter set' is the -w option, but the workspace folder some-package-name definitely exists.

One note is that the some-package-name/package.json contains an org prefix, eg:

"name": "@mycompany/some-package-name",

So maybe that's the cause. I can't rename the folder from some-package-name to @mycompany/some-package-name though as I'm concerned a directory starting with @ may break things.

What does the warning mean and how can I resolve it?

Upvotes: 25

Views: 14305

Answers (5)

Kusmeroglu
Kusmeroglu

Reputation: 301

I ran into the same problem, using the name configured in the workspace's package instead of the folder name fixed the issue for me, even with an @.

npm install --workspace=@mycompany/some-package-name

The issue may appear for the package in question package.json and package-lock.json name fields do not match the workspace folder naming and package name and / or each other.

The command updated both name fields so that the warning is gone.

Upvotes: 8

Raman
Raman

Reputation: 11

For me I was getting this warning/issue when I was using monorepo using turborepo, created using command - npx create-turbo@latest.

I was getting the error because I changed the name of the nextjs project. But I didn't change the name property in package.json. When name property was changed to name of the folder/package, issue was resolved.

Once you change the name property in package.json, make sure you re-install the tailwind or any other packages you were installing. It will not prompt the above error.

Refer to the below image: the name of the package/project is user-app but in the package.json name is web, I edited this name to user-app and the issue was resolved.

enter image description here

Upvotes: 1

kukuruznik
kukuruznik

Reputation: 126

I have run into the same problem recently with my monorepo: the reason was that the project's name (without the scope) in package.json did not match the name of the directory (subproject) it was stored within.

If the subprojects of the monorepo are stored within a packages directory in the project root and the root package.json contains

"workspaces": [
    "packages/*"
]

then npm expects a subproject named @<scope>/project-name to be in the directory packages/project-name.

Upvotes: 7

Gianluca Casati
Gianluca Casati

Reputation: 3753

I solved this issue using a file: dependency as "recommended by npm" (read below).

Actually many articles say that npm recommends to use file: to reference a dependency between two workspace packages (and then often they use the asterisk anyway) but honestly I did not found that hint in npm docs, but it works! ... at least it worked for me, using the following

Explicitly list the workspaces

So instead of using an asterisk I have, for example

  "workspaces": [
    "packages/models",
    "packages/database",
    "webapp"
  ]

I also have a scoped package name

for instance

  "name": "@project/models",
  "private": "true"

I am using "file:" dependencies

Instead of

  "dependencies": {
    "@project/models": "*"
  }

I use file:WORKSPACE_PATH

  "dependencies": {
    "@project/models": "file:packages/models"
  }

Upvotes: 1

Dave Stewart
Dave Stewart

Reputation: 2524

I have a slightly different answer.

I'm creating a package.json programatically, using Fs.writeFileSync('./path/to/package.json').

I run npm install -w=workspace foo bar immediately after, but it seems that this fails sometimes; NPM somehow hasn't picked up on the file, as if I run the same command twice, the second one always works.

Adding a small delay using setTimeout() also works, though I feel a bit dirty having had to do this; I don't know if this is an issue with Node or my lack of knowledge around Node's process lifecycle.

Anyway, in this case – and in lieu of better solution – it works.

Upvotes: 1

Related Questions