Unmet peer deps with workspaces #5810
Comments
ghost
assigned 
|
I don't think I'm using the workspace feature, but am getting the following error despite the fact that warning "react-intl-cra > babel-preset-react-app@3.1.1" has unmet peer dependency "babel-runtime@^6.23.0".My packages:{
"dependencies": {
"babel-polyfill": "^6.26.0",
"classnames": "^2.2.5",
"eventemitter3": "^3.1.0",
"history": "^4.7.2",
"invariant": "^2.2.4",
"lodash.debounce": "^4.0.8",
"path-to-regexp": "2.2.1",
"prop-types": "15.6.1",
"query-string": "5.1.1",
"react": "16.4.0",
"react-bootstrap": "0.32.1",
"react-delay-input": "^4.0.4",
"react-dom": "16.4.0",
"react-input-mask": "2.0.1",
"react-intl": "^2.4.0",
"react-loadable": "5.4.0",
"react-overlays": "^0.8.3",
"react-redux": "5.0.7",
"redux": "^3.7.2",
"redux-devtools-extension": "^2.13.2",
"redux-logger": "^3.0.6",
"redux-persist": "4.10.2",
"redux-persist-crosstab": "^3.7.0",
"reselect": "^3.0.1",
"symbol-observable": "1.0.4"
},
"devDependencies": {
"bootstrap": "3",
"grunt": "1.0.3",
"grunt-contrib-less": "^1.4.1",
"grunt-contrib-watch": "1.1.0",
"grunt-minify-html": "^3.0.0",
"less-plugin-autoprefix": "^1.5.1",
"less-plugin-clean-css": "^1.5.1",
"npm-run-all": "4.1.3",
"react-intl-cra": "0.3.3",
"react-intl-po": "2.2.2",
"react-scripts": "1.1.4"
}
} |
|
Actually, I get the same error even when I merge all of my dependencies under I don't get this error in either situation when using npm v5.5.1. |
|
@waynebloss you say you have I reckon |
|
@sheepsteak |
|
@waynebloss Peer dep requirements need to be explicitly defined, not implicit. |
|
i wonder if this pr may fix this. @rally25rs https://github.com/yarnpkg/yarn/pull/6012/files |
|
Getting this issue with yarn v1.9.2. I haven't tried putting the deps in |
|
I'm also affected over here. I'm also using lerna, however if I do a yarn install in each package without workspaces I don't get any warnings so I believe this is related. node: v8.11.1 output: |
|
Bumping as this is still an issue in yarn 1.15 |
|
Yea, I'm seeing this as well. We have our mono-repo broken into two workspaces. A The problem I run into is that any package that defines a peerDep, ends up throwing a warning, depsite the face that the dep is also installed as a devDep in that package, and the service that imports it has the peerDep installed into it's main dependencies. |
|
This is a pretty serious annoyance as our project is growing. So many of our workspace packages depend on peerDeps that the list of warnings that mean nothing is growing and growing.
|
|
Just my two cents..: The workspace is private anyways, it will not be consumed by any packages, so it's "peerDeendencies" field is basically unused. Whenever yarn would complain about a missing peer dependency, it could now check if the dependency in question is defined in the workspace peerDependencies, and if so, omit the warning. |
peerDependencies in the packages were throwing warnings, potentially related to yarnpkg/yarn#5810. In this commit, we rework the peerDependency definitions to align better with the conventions outlined in the main peerDependency documentation, and we define devDependencies both at the top level and at the package level, since package-level is technically closer to "correct" but it doesn't satisfy the checks in yarn yet. In addition, we've bumped a few versions and aligned across the packages where duplication occurs, which led to our tests running into jsx-eslint/eslint-plugin-react#2329 for our "detect" mode in eslint-plugin-react.
peerDependencies in the packages were throwing warnings, potentially related to yarnpkg/yarn#5810. In this commit, we rework the peerDependency definitions to align better with the conventions outlined in the main peerDependency documentation, and we define devDependencies both at the top level and at the package level, since package-level is technically closer to "correct" but it doesn't satisfy the checks in yarn yet. In addition, we've bumped a few versions and aligned across the packages where duplication occurs, which led to our tests running into jsx-eslint/eslint-plugin-react#2329 for our "detect" mode in eslint-plugin-react.
|
Bumping for update |
|
Same issue for me. I checked my peer dependencies. They are correct but I get these warnings |
|
Same issue :( |
Common build dependencies across sub-packages can get out-of-sync over time. Currently, `rollup` and plugins is used across both `test-utils` and `server-test-utils`, but different versions are specified. This requires duplicate installations, and prevents hoisting. Since `devDependencies` are not present in published packages, and since the monorepo is used exclusively for building the subpackages, it makes sense to define all build dependencies in the root package. Move all `devDependencies` in the root package to `dependencies`, to avoid unmet peer dependency errors in `yarn`: yarnpkg/yarn#5810 Update each of these dependencies to their latest version, in particular `rollup`, which has since released stable versions. See https://github.com/lerna/lerna/blob/master/doc/hoist.md#lerna-hoisting
* Update lockfile `yarn install` was failing with newer node versions (>=10) because the version of fsevents was too old (no precompiled binaries), and node-gyp would fail to build it. `yarn upgrade` mitigates this issue, but a change in `prettier` 1.18 (https://prettier.io/blog/2019/06/06/1.18.0.html) required `yarn format` to also be run. A missing dependency (`rollup-plugin-json`) was added to `@vue/test-utils`, as it is imported in its build script. * Update compatibility test versions Update minor versions of running `yarn test:compat` to the latest patch revisions. Add optional argument to `yarn test:compat`, to allow running tests against arbitrary `vue` versions. Run compatibility tests in reverse order, to ensure the most relevant test failures are displayed. Run `yarn add` non-interactively, to force errors if `yarn test:compat` is passed an invalid value. Run `yarn add` without clobbering the lockfile. * Update CircleCI config for compatibility tests Having each compatibility test version specified in both the CI config and the package script leads to inconsistencies over time. The CI config can just use the package script. * Hoist dev dependencies explicitly Common build dependencies across sub-packages can get out-of-sync over time. Currently, `rollup` and plugins is used across both `test-utils` and `server-test-utils`, but different versions are specified. This requires duplicate installations, and prevents hoisting. Since `devDependencies` are not present in published packages, and since the monorepo is used exclusively for building the subpackages, it makes sense to define all build dependencies in the root package. Move all `devDependencies` in the root package to `dependencies`, to avoid unmet peer dependency errors in `yarn`: yarnpkg/yarn#5810 Update each of these dependencies to their latest version, in particular `rollup`, which has since released stable versions. See https://github.com/lerna/lerna/blob/master/doc/hoist.md#lerna-hoisting * Remove build step from compatibility tests Each compatibility test installs a legacy version of `vue`, and builds each package against this version before running the test suites. This is assumedly in error, as the only build that gets published is the one built against the dependencies in the lockfile. To properly test compatibility for consumers using older versions of `vue` to satisfy each package's peer dependency, we need to test against the build that would actually get published. The fix is to run `yarn build:test` only once, before any compatibility tests are run. * Relax rollup dependency constraints The upgrade from `rollup` beta -> stable went without breakages, so clearly we don't need to overly constrain updated dependencies using the `^` semver specifier. * Revert locked dependencies The updates from 1d6950a have to be partially reverted to allow for the last compatiblity test suite to pass: `vue@2.0.8`. There is some unclear combination of dependencies that causes 80 unit test failures for only the 2.0 version of vue.
|
same issue here |
|
Same issue here with yarn 1.21.1. |
|
+1 |
|
Does anyone know if this is resolved with Yarn 2? I haven't made the switch yet but I would be OK with having to in order to fix this. |
|
@rikkit I no longer have this problem with Yarn 2, 0 warning. Yarn 2 is more strict on the resolution of peerDependancies but allows to make optionalPeerDependencies and/or to overload the packages with missing peerDependencies. |
|
same here with yarn@1.22.5 |
|
Closing as fixed in v2 |
merceyz
added
the
fixed-in-modern
This silences the yarn warning for missing peer dependency for `@nighttrax/components`. This is actually a bug in yarn: yarnpkg/yarn#5810. I don't particularly like the workaround, but better than a noisy warning, I guess? Fixes #60.
|
Why is this closed? React Native projects do not play nicely with yarn 2, and all these warnings are annoying |
and others
Do you want to request a feature or report a bug?
Bug
What is the current behavior?
In workspaces,
peerDependenciesthat are also present asdevDependenciesare reported as unmet.If the current behavior is a bug, please provide the steps to reproduce.
Clone https://github.com/sky87/unmet-peer-deps-issue, run
What is the expected behavior?
Yarn should not issue a warning.
Notice that without workspaces everything works as expected.
Please mention your node.js, yarn and operating system version.
The text was updated successfully, but these errors were encountered: