Module not found: Can't resolve 'p-queue' in '/app/node_modules/@uppy/provider-views/lib/ProviderView'

[tnhgiang]

Initial checklist

• I understand this is a bug report and questions should be posted in the Community Forum
• I searched issues and couldn’t find anything (or linked relevant results below)

Link to runnable example

No response

Steps to reproduce

My package.json:

{
"dependencies": {
"@uppy/core": "^3.0.4",
"@uppy/dashboard": "^3.2.0",
"@uppy/drag-drop": "^3.0.1",
"@uppy/file-input": "^3.0.1",
"@uppy/google-drive": "^3.0.1",
"@uppy/locales": "^3.0.4",
"@uppy/progress-bar": "^3.0.1",
"@uppy/react": "^3.0.2",
"@uppy/remote-sources": "^1.0.2",
"@uppy/tus": "^3.0.5",
"@uppy/xhr-upload": "^3.0.4",
},
}

My minimal yarn.lock:

• @uppy/onedrive use the latest version of @uppy/provider-views

"@uppy/onedrive@^3.1.1":
version "3.1.3"
dependencies:
"@uppy/companion-client" "^3.3.0"
"@uppy/provider-views" "^3.5.0"
"@uppy/utils" "^5.4.3"
preact "^10.5.13"

• @uppy/provider-views use the p-queue package

"@uppy/provider-views@^3.5.0":
version "3.5.0"
dependencies:
"@uppy/utils" "^5.4.3"
classnames "^2.2.6"
nanoid "^4.0.0"
p-queue "^7.3.4"
preact "^10.5.13"

• p-queue package

p-queue@^7.3.4:
version "7.3.4"
dependencies:
eventemitter3 "^4.0.7"
p-timeout "^5.0.2"

Error log:

./node_modules/@uppy/provider-views/lib/ProviderView/ProviderView.js
Module not found: Can't resolve 'p-queue' in '/app/node_modules/@uppy/provider-views/lib/ProviderView'

Expected behavior

• Uppy must start and run smoothly

Actual behavior

• Module not found: Can't resolve 'p-queue' in '/app/node_modules/@uppy/provider-views/lib/ProviderView'

[Murderlon]

Hi, this seems to be an issue with your build setup, very likely because your app doesn't (fully) support ESM. We test against all major bundlers in CI and on production systems where uppy is integrated. Closing as there is not enough information to help but we can continue the discussion.

[Gecko-Web]

Same issue here.

My way to fix this is to edit the file
node_modules/@uppy/provider-views/lib/ProviderView/ProviderView.js
On line 6: replace import PQueue from 'p-queue'; with import PQueue from 'p-queue/dist';

It's quite dirty but it's the only solution I found to make it work (webpack 4.46)

@Murderlon : note the comment //eslint-disable-next-line import/no-unresolved just before the problematic line. This looks like a workaround for an import problem, right? ;)

Does anyone here have another idea?

[Murderlon]

I faced this locally too yesterday. Will take a look Monday.

[Gecko-Web]

@Murderlon There is already a pull request (marked as draft 3 months ago) for this issue : #4530

[Murderlon]

Discussed with @arturi @aduh95 @mifi, this is not something we can fix. Adding /dist to the import is a hack that will fail other bundlers. If your bundler doesn't support it, or if p-queue incorrectly exports files, it should be fixed there and not downstream.

You can patch for your app though, as we do: https://github.com/transloadit/uppy/pull/4640/files#diff-57a642bb288f1faded77fcf3e5cf8a8771e787a7583072f75e55eca777f8865b

[mdxiaohu]

@Murderlon Nevertheless, I don't quite understand how to operate it. I also encountered this issue. Can I directly replace the file for this example?

[Murderlon]

You can use something like patch-package or the built-in yarn patch to add "main": "./dist/index.js", to p-queue's package.json. Note that main should not be used for for ESM packages with exports, but for certain bundlers it may fix it.

[mdxiaohu]

@Murderlon My operation is to directly run 'Yarn add p-queue' and then run it on node_ Found p-queue package in the modules folder. Then delete the 'exports' attribute and add the' main 'attribute. The project is ready to run, I'm not sure if this is possible.

I did not use 'patch-package' and 'Yarn patch', but instead used the most primitive manual operation .
The project is running normally, and the errors have also disappeared .

[Murderlon]

I did not use 'patch package' and 'Yarn patch', but instead used the most primitive manual operation .

That works locally, but how will that work in production or for anyone else?

[mdxiaohu]

@Murderlon

Thank you very much. It's great to receive a response.
I haven't tested whether it will take effect after the project is packaged.
Logically speaking, after packaging, the projects deployed online should be consistent with the local and also usable.
Of course, as I am the only one responsible for project development, I can temporarily operate it manually.

Indeed, for situations where multiple developers are involved, my approach is not very applicable. I am not very familiar with the "patch-package" and "yarn patch" operations, and currently manual changes can only solve the problem with my local project.

I searched for a simple usage of 'patch-package' in ChatGPT, but there were some errors in my usage,
However, I will continue to try the 'patch-package' operation. Thank you again for letting me know about this 'patch-package '.

[Murderlon]

Logically speaking, after packaging, the projects deployed online should be consistent with the local and also usable.

But node_modules is in .gitignore so if you edit it your edit won't be in git for anyone else and more importantly it won't be there when npm ci (or whatever package manager you use) is ran before a deployment?

[mdxiaohu]

@Murderlon

I have recorded this issue in README. If there is still a problem with a different computer, please follow the recorded operation.

Generally, both running and packaging are in my local project, which can be done locally, but should be possible online.

Of course, I will test the situation after the project deployment goes live .