Closed edmorley closed 7 years ago
This also reproduces with yarn 1.2.1.
This doesn't seem like a bug to me. neutrino-preset-airbnb-base
does not list anything related to eslint
in its dependencies and I get the following warnings when I try:
warning "neutrino-preset-airbnb-base > eslint-config-airbnb-base@12.0.2" has unmet peer dependency "eslint@^4.8.0".
warning "neutrino-preset-airbnb-base > eslint-plugin-import@2.7.0" has unmet peer dependency "eslint@2.x - 4.x".
This plugin and the config are direct dependencies of neutrino-preset-airbnb-base
so there should be an ESLint dependency listed compatible with these ranges in the same tree. That means either at the project root or inside neutrino-preset-airbnb-base
itself. I'm guessing NPM doesn't complain about this since neutrino
lists ESLint as a dependency and and it gets hoisted up to the project root. That said this is not guaranteed at all cases (hoisting is never guaranteed), so Yarn's warning is correct.
But neutrino-preset-airbnb-base
lists neutrino-middleware-eslint
as a dependency, which does depend on eslint
. I know this relies on hoisting to work, but this is the intended use-case - these are handy wrappers around common configuration, where the user isn't meant to have to install additional dependencies at the top level, nor do we want neutrino-preset-airbnb-base
to use a different eslint version from neutrino-middleware-eslint
. (And in fact, neither neutrino-preset-airbnb-base
nor neutrino-middleware-eslint
will directly use eslint, the neutrino
main package will).
Is this just a workflow not very well supported by peerDependencies
at the moment?
Perhaps a middle ground would be for yarn to only warn in this case if it wasn't hoisting? Since if hoisting occurs then it's not actually an issue - and for Neutrino (and other ecosystems that use a similar plugin system), the hoisting is actually necessary/expected otherwise nothing would work.
@edmorley any chance you found a resolution to this issue? I'm using neutrino as well and it is frustrating to get a bunch of warnings we don't technically control.
@mpolichette I haven't sadly.
@BYK, what do you think about:
Perhaps a middle ground would be for yarn to only warn in this case if it wasn't hoisting? Since if hoisting occurs then it's not actually an issue - and for Neutrino (and other ecosystems that use a similar plugin system), the hoisting is actually necessary/expected otherwise nothing would work.
I think this is supposed to be fixed in v1.4.0... https://github.com/yarnpkg/yarn/pull/5088
This issue is about cases where the dep isn't at root level intentionally, but will be after hoisting. So isn't fixed in the latest release.
and for Neutrino (and other ecosystems that use a similar plugin system), the hoisting is actually necessary/expected otherwise nothing would work.
i seem to agree with this statement.
Hi!
Do you want to request a feature or report a bug? A bug.
STR:
rm -rf node_modules/ && yarn install
rm -rf node_modules/ && npm install
Expected:
package.json
.Actual: The yarn output (example) includes:
...whereas the NPM output (example) contains no such warnings.
To save having to dig through the repo, the testcase's package.json contains:
...and the relevant child package's dependencies are as follows:
Please mention your node.js, yarn and operating system version. yarn 1.2.0 / npm 5.4.2 node 8.6.0 Windows 10 x64 using MSYS2 bash.
Many thanks :-)