Olivier Tassinari

@diegohaz Thank you for opening this issue. I'm happy to see these two new helpers in React core. I'm not sure how we should handle them.

We will have to write a branch statement with React.warn, the overhead of adding an extra !== production condition is small. Maybe we should deprecate this babel plugin 🤔. In...

@sonaye In this case, we miss a test to assert it :)

@nijk Thanks for the reproduction. It sounds like a bug.

I'm closing, the react popper issue is too high level. It doesn't mean it's an issue with this Babel plugin. Library authors should use the wrap mode. They should have...

> 1. When using the remove mode (default) the propTypes were not removed from either SFC or the ClassComponent. We should fix that: https://github.com/nijk/babel-plugin-transform-react-remove-prop-types-issue-140. > 2. When using the wrap...

@PeoB I have upgraded the dependency to v0.4.20 in https://github.com/mui-org/material-ui/pull/13540 without any issue. Do you have a reproduction example?

> @oliviertassinari do you have any ideas on how static class propTypes properties can be removed from ClassExpressions in wrap mode? We are already supporting it this use case. The...

@lencioni What makes you think this plugin can be more efficient at removing dead code than another tool specifically tailored for it? I mean, if a dead code prunner can't...

I don't think that it should be the default behavior given the potential side effects you mentioned, at the exception of `prop-types` that is side-effect free, so we can do...