Bug(regression): PropTypes.resetWarningCache has no effect in react@next

React version: 0.0.0-235a6c4af

Steps To Reproduce

1. render component with exptected propType warnings
2. see logged errors
3. call PropTypes.resetWarningCache()
4. render component with exptected propType warnings
5. no more logged errors

Link to code example:

import React from "react";
import ReactDOM from "react-dom";
import PropTypes from "prop-types";

function Component({ children = "setting default to not crash react" }) {
  return children;
}

Component.propTypes = { children: PropTypes.node.isRequired };

const rootElement = document.createElement("div");

ReactDOM.render(<Component />, rootElement);
PropTypes.resetWarningCache();
ReactDOM.render(<Component />, rootElement);

Behavior on 0.0.0-235a6c4af Behavior on 16.13.0

The current behavior

Warnings are logged once

The expected behavior

Warnings are logged twice. This was the behavior in 16.13.0

Context

Useful for testing custom propTypes warnings. When a test is watched and modules can’t be reset between runs resetWarningCache was useful. Otherwise the test behavior would change between test runs.

Pretty sure this is caused by inlining prop-types in #18127. I think we can keep inlining the code and only import the cache so that it is shared with the regular prop-types package and PropTypes.resetWarningCache() keeps working.

[gaearon]

This is a bit unfortunate. But to be honest, we didn’t really sign up to respect this setting in React itself. The fact that the prop-types module used by React was technically shared is an implementation detail that could easily change, e.g. if we pinned our version.

Useful for testing custom propTypes warnings. When a test is watched and modules can’t be reset between runs resetWarningCache was useful. Otherwise the test behavior would change between test runs.

While I probably won’t convince you, jest.resetModules() in beforeEach + CommonJS in tests does this too. That’s what we’ve been using. It works pretty well and resets other state you might want to make isolated.

I think we can keep inlining the code and only import the cache so that it is shared with the regular prop-types package and PropTypes.resetWarningCache() keeps working.

The purpose was to get rid of imports.

I’m still not really clear on the value of having fewer dependencies, especially in the case of prop-types, which facebook controls.

Prop-types is a legacy feature. It’s not something that is super important to React going forward. We try to keep it working, but it’s not a first-class “React API”. There is no need for us to keep the implementation separate when the contract is so simple and we could just call into the user code from React here.

On the other hand, changes related to ESM and just our bundling process is always more complicated when there’s dependencies involved. We have so few dependencies that this isn’t worth the complexity. It is easier to get rid of them.

[eps1lon]

I’ll ping you in the PR where we migrate from .propTypes to checkPropTypes since I want to go over these custom propTypes myself just in case they are actually not necessary.

See https://github.com/mui-org/material-ui/pull/20451