Bug: [email protected] incorrectly peer-depends on react@^16.0.0

[billyjanitsch]

React version: [email protected]

Steps To Reproduce

1. Run npm view [email protected] dependencies.
2. Note the dependency on react-shallow-renderer@^16.13.1.
3. Run npm view [email protected] peerDependencies.
4. Note the peer dependency on react@^16.0.0.

Alternatively, in an empty project:

1. Run npm install react@17 react-test-renderer@17.
2. Note the invalid peer dependency warning.

The current behavior

It doesn't make sense for react-test-renderer@17 to transitively peer-depend on react@16. I assume this was an oversight in the release.

The expected behavior

One should be able to install react@17 and react-test-renderer@17 and have the peer dependencies line up.

[gaearon]

Yeah there was some awkwardness here because react-shallow-renderer also depends on react-is. I think we need to make a release of react-shallow-renderer first which bumps to 17 and then do another patch of 17.

[billyjanitsch]

It actually appears to be a mistake for react-test-renderer to depend on react-shallow-renderer at all. [email protected] has no dependency on react-shallow-renderer, and there are no references to it in the source.

The dependency was added in #18348 but maybe that was an oversight?

[gaearon]

No, it definitely uses it: https://unpkg.com/browse/[email protected]/shallow.js

You mean to look at 16.14, not 16.4?

[billyjanitsch]

Oh, my bad, I was looking in the src/ directory only.

(And yeah, "16.4" was a typo; I meant "16.14". See the output of npm view [email protected] dependencies.)

[billyjanitsch]

enzymejs/react-shallow-renderer#93 will usually work but it will break backwards compatibility in certain situations. Specifically, it's possible to end up with a deps tree that npm considers valid but that will break at runtime, e.g.:

npm i https://github.com/NMinhNguyen/react-shallow-renderer#dccc711
npm i react@16

This produces the following tree, with conflicting versions of react-is:

├─┬ [email protected]
│ ├─┬ [email protected]
│ │ └── [email protected]
│ ├── [email protected]
│ └─┬ [email protected]
│   ├── [email protected]
│   ├── [email protected]
│   └── [email protected]
└─┬ [email protected] (git+https://github.com/NMinhNguyen/react-shallow-renderer.git#dccc7112e4606ea10a8125d8333ac5a86f5f3101)
  ├── [email protected]
  └── [email protected]

In general, this will happen any time that a version of react-shallow-renderer that depends on ^16.12.0 || ^17.0.0 is installed before react-is@16 already exists in the tree. npm won't dedupe the dep later.

Maybe you consider this too unlikely to warrant fixing?

[gaearon]

Why do you think this would break at runtime? That module is stateless.

[gaearon]

Should be fixed.

[billyjanitsch]

Thanks; sorry for the assertive framing without context. I looked more closely at react-test-renderer and I see that it only ever uses react-is to test for specific element types so it won't break.

(The problem I was imagining is if it were using something like isValidElementType and the 17 element types eventually changed over time, e.g., by addition of new types, such that the shallow renderer would get assertions that would be inaccurate from the POV of React 16.)