Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] webpack cannot access webpack-cli with workspaces #556

Closed
HosseinAgha opened this issue Oct 30, 2019 · 6 comments
Closed

[Bug] webpack cannot access webpack-cli with workspaces #556

HosseinAgha opened this issue Oct 30, 2019 · 6 comments
Labels
bug Something isn't working external bug This issue highlights a bug in another project stale Issues that didn't get attention

Comments

@HosseinAgha
Copy link

HosseinAgha commented Oct 30, 2019

Describe the bug

webpack-cli throws an error "One CLI for webpack must be installed." in a workspace but works fine in a single package.
I think this may be a major bug with binaries and workspaces in berry.

To Reproduce

Checkout the repro repository: https://github.com/HosseinAgha/yarn2-workspaces-webpack-bug-repro

@HosseinAgha HosseinAgha added the bug Something isn't working label Oct 30, 2019
@HosseinAgha HosseinAgha changed the title [Bug] webpack-cli binary will not install correctly in a workspace [Bug] webpack-cli binary will not install correctly in a workspaced project Oct 30, 2019
@arcanis
Copy link
Member

arcanis commented Oct 30, 2019

It's a Webpack bug. They are using require.resolve to check whether webpack-cli is installed, but they don't run it on behalf on their parent package. This causes Yarn to reject the resolution because webpack-cli isn't a dependency of webpack.

Three solutions:

  • As a short-term option, you can use yarn webpack-cli ..., which is the real name of the binary exposed by webpack-cli.

  • The webpack package should declare webpack-cli (and webpack-command) as optional peer dependencies. This formal declaration will give it access to its neighbour packages.

  • Or the webpack package should require webpack-cli on behalf of the userland code by using something similar to createRequire. The trick is to find on behalf of who should the call be made - my best guess would be process.env.INIT_CWD.

@arcanis arcanis added the external bug This issue highlights a bug in another project label Oct 30, 2019
@arcanis arcanis changed the title [Bug] webpack-cli binary will not install correctly in a workspaced project [Bug] webpack cannot access webpack-cli in a workspaced project Oct 30, 2019
@arcanis arcanis changed the title [Bug] webpack cannot access webpack-cli in a workspaced project [Bug] webpack cannot access webpack-cli with workspaces Oct 30, 2019
@andreialecu
Copy link
Contributor

andreialecu commented Jan 22, 2020

I've ran into the same issue but with webpack-dev-server:

Error: A package is trying to access another package without the second one being listed as a dependency of the first one

Required package: webpack-cli (via "webpack-cli/bin/config-yargs")
Required by: webpack-dev-server@virtual:1e73a2e864eda574311f3ce8fb25ed7e0b40837cf3d41b48f72db6961ea7b29e054e2ef16981aea4a4b040cdb56a1a6f9fe63ce21114147e55edb38884db917e#npm:3.10.1

Since the command being ran is already yarn webpack-dev-server, I'm not sure how to get around this and get unblocked. Any ideas?

Edit: Just found this PR: webpack/webpack-dev-server#2396 - guess I'll use that branch until it's merged.

@arcanis
Copy link
Member

arcanis commented Jan 22, 2020

Note that you can use packageExtensions to fix the problem in your repo.

@andreialecu
Copy link
Contributor

Adding this to .yarnrc.yml got past it:

packageExtensions:
  webpack-dev-server@*:
    peerDependencies:
      webpack-cli: "*"

@o-alquimista
Copy link

Is my issue a duplicate of this?

@yarnbot
Copy link
Collaborator

yarnbot commented Jun 9, 2020

Hi! 👋

This issue looks stale, and doesn't feature the reproducible label - which implies that you didn't provide a working reproduction using Sherlock. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we're a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolution faster). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it's a Windows-only issue), a maintainer will have to manually add the upholded label.

@yarnbot yarnbot added the stale Issues that didn't get attention label Jun 9, 2020
@yarnbot yarnbot closed this as completed Jun 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working external bug This issue highlights a bug in another project stale Issues that didn't get attention
Projects
None yet
Development

No branches or pull requests

5 participants