Open rtritto opened 3 years ago
Most of these seem to be because you did not copy the full install command. Yes, if you strip out next
, you're going to get warnings. Same goes for the aliased react
& react-dom
.
Any reason why you're using
yarn add preact preact-render-to-string preact-ssr-prepass next-plugin-preact
instead of the install command that's listed in the ReadMe? Please use the one provided and try again.
yarn add next next-plugin-preact preact react@npm:@preact/compat react-dom@npm:@preact/compat react-ssr-prepass@npm:preact-ssr-prepass preact-render-to-string
@rschristian thanks for answer.
Any reason why you're using
yarn add preact preact-render-to-string preact-ssr-prepass next-plugin-preact
I tried to create minimal steps to reproduce warnings.
Command:
yarn add next next-plugin-preact preact preact-render-to-string react@npm:@preact/compat@* react-dom@npm:@preact/compat@* react-ssr-prepass@npm:preact-ssr-prepass@*
yarn log:
➤ YN0000: ┌ Resolution step
➤ YN0032: │ evp_bytestokey@npm:1.0.3: Implicit dependencies on node-gyp are discouraged
➤ YN0061: │ querystring@npm:0.2.0 is deprecated: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
➤ YN0061: │ querystring@npm:0.2.1 is deprecated: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
➤ YN0032: │ fsevents@npm:2.3.2: Implicit dependencies on node-gyp are discouraged
➤ YN0032: │ fsevents@npm:2.3.2: Implicit dependencies on node-gyp are discouraged
➤ YN0002: │ next-plugin-preact@npm:3.0.6 [99790] doesn't provide @prefresh/babel-plugin (p48563), requested by @prefresh/webpack
➤ YN0002: │ next-plugin-preact@npm:3.0.6 [99790] doesn't provide next (p7b6b4), requested by @prefresh/next
➤ YN0002: │ next-plugin-preact@npm:3.0.6 [99790] doesn't provide webpack (p67555), requested by @prefresh/next
➤ YN0002: │ next-plugin-preact@npm:3.0.6 [99790] doesn't provide webpack (p99d5e), requested by @prefresh/webpack
➤ YN0002: │ yarnpreact@workspace:. doesn't provide preact-ssr-prepass (p28444), requested by next-plugin-preact
➤ YN0000: │ Some peer dependencies are incorrectly met; run yarn explain peer-requirements <hash> for details, where <hash> is the six-letter p-prefixed code
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0013: │ wide-align@npm:1.1.3 can't be found in the cache and will be fetched from the re
➤ YN0013: │ wrappy@npm:1.0.2 can't be found in the cache and will be fetched from the remote
➤ YN0013: │ xtend@npm:4.0.2 can't be found in the cache and will be fetched from the remote
➤ YN0013: │ yallist@npm:4.0.0 can't be found in the cache and will be fetched from the remot
➤ YN0013: │ yocto-queue@npm:0.1.0 can't be found in the cache and will be fetched from the r
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0007: │ next-plugin-preact@npm:3.0.6 [99790] must be built because it never has been before or the last one failed
➤ YN0000: └ Completed
➤ YN0000: Done with warnings
Sounds like wonky resolution with Yarn 2 if it thinks next
isn't provided when you've already installed it.
I'm using latest yarn berry version (currently 3.0.2) with a clean project:
yarn init -y
yarn set version berry
yarn add next next-plugin-preact preact preact-render-to-string react@npm:@preact/compat@* react-dom@npm:@preact/compat@* react-ssr-prepass@npm:preact-ssr-prepass@*
This seems to be another one of Yarn 2's infamous problems. You'll either need to ignore the warnings (as they're, at least mostly, wrong) or move to a tool that doesn't have these sorts of issues.
FYI @arcanis @merceyz
This seems to be another one of Yarn 2's infamous problems. You'll either need to ignore the warnings (as they're, at least mostly, wrong) or move to a tool that doesn't have these sorts of issues.
Ouch, the warnings are correct though and Yarn 1.x gives the same complaints, next-plugin-preact@3.0.6
doesn't declare any of them as neither dependencies
nor peerDependencies
so under strict dependency rules they aren't available and under node_modules
it will rely on hoisting to be in its favour.
@arcanis wrote an article on the subject https://dev.to/arcanis/implicit-transitive-peer-dependencies-ed0
@merceyz Yarn 1 does not give the same complaints, at least not fully. The warning against next
being provided certainly doesn't show up, beyond that, I didn't look too closely, as that's clearly an error in Yarn 2.
I didn't look too closely, as that's clearly an error in Yarn 2.
No, this is entirely intended. It's not an "infamous problem", it's a documented behaviour. Transitive peer dependencies must be declared all the way for both technical and semantic reasons.
No, this is entirely intended.
Something can be intentional and still an error to the larger community.
It's not an "infamous problem", it's a documented behaviour.
Behavior being documented doesn't mean it's not a problem. It's not hard to find hundreds of issues across popular projects with Yarn 2. A tool that has little use (compared to NPM & Yarn 1) that goes a different direction behaviorally, documented or not, is a problem. Combine that with other differences and you an infamous tool that creates problems wherever it goes.
Transitive peer dependencies must be declared all the way for both technical and semantic reasons.
I don't see the use in fixing warnings that pop up only in a single tool. Those "technical and semantic reasons" need to adhere to the larger ecosystem of standards and practices.
I'll certainly take a look myself if someone creates a PR (as any other maintainer could do) but I can't say I see the point in resolving Yarn 2+ issues after years of this.
Thanks to all for answers.
Same warnings log with yarn v1.22.11:
yarn init -y
yarn add next next-plugin-preact preact preact-render-to-string react@npm:@preact/compat@* react-dom@npm:@preact/compat@* react-ssr-prepass@npm:preact-ssr-prepass@*
So package.json should be updated as follow:
{
...
"dependencies": {
...
"@prefresh/babel-plugin": "<min_version>",
"webpack": "<min_version>"
},
"peerDependencies": {
...
"next": "<min_version>",
"react": "<min_version>",
"react-dom": "<min_version>"
}
}
@arcanis can exists a protocol (maybe a feature) to inherit peerDependencies and all (recursively) its peerDependency (transitive dependencies)?
Example for this use case:
Inherit all peerDependency of @prefresh/next
(next
and all its peerDependencies (react
and react-dom
)).
peerDependency tree:
@prefresh/next
next
react
react-dom
Change from:
{
...
"peerDependencies": {
"next": "<min_version>",
"react": "<min_version>",
"react-dom": "<min_version>"
}
}
to:
{
...
"peerDependencies": {
"@prefresh/next": "<inherit_protocol_for_all_peerDependencies_of_@prefresh/next>"
}
}
I don't see the use in fixing warnings that pop up only in a single tool. Those "technical and semantic reasons" need to adhere to the larger ecosystem of standards and practices. I'll certainly take a look myself if someone creates a PR (as any other maintainer could do) but I can't say I see the point in resolving Yarn 2+ issues after years of this.
@rschristian npm also doesn't see it as provided and will install a separate version if they can't be deduped to the same version without issuing a warning
{
"dependencies": {
"next": "11.1.3-canary.7",
"next-plugin-preact": "3.0.6",
"preact": "10.5.14",
"preact-render-to-string": "5.1.19",
"react": "npm:@preact/compat@17.0.2",
"react-dom": "npm:@preact/compat@17.0.2",
"react-ssr-prepass": "npm:preact-ssr-prepass@1.2.0"
}
}
$ npm --version && npm i && find node_modules/**/next/ -maxdepth 1 -type d
7.21.1
[...]
node_modules/next-plugin-preact/node_modules/next/
[...]
node_modules/next/
[...]
Summary
After I install
next-plugin-preact
withyarn
(berry version), I get dependency not found warnings in yarn log.Respectively peerDeependencies:
next
andwebpack
are of@prefresh/next
react
andreact-dom
are ofnext
@prefresh/babel-plugin
andwebpack
are of@prefresh/webpack
They should be added in package.json
Versions
next-plugin-preact
: 3.0.6Steps Reproduce
yarn init -y
yarn set version berry
yarn add preact preact-render-to-string preact-ssr-prepass next-plugin-preact
Results
Actual
yarn log:
Expect
No warning in yarn log.
Workaround
Add in
.yarnrc.yml
: