Next.js: Ability to Configure `transform-react-remove-prop-types` for `next/babel` Preset

[JHawkley]

Feature request

Is your feature request related to a problem? Please describe.

I'm currently making use of custom prop-types and virtual methods, using the experimental bind syntax, to add new assertions to my component's properties. Using these has made it impossible for the transform-react-remove-prop-types plugin to properly remove them, since it doesn't recognize these modules as being related to prop-types.

An example demonstrating the problem:

import React from "react"
import PropTypes from "prop-types"
import ExtraTypes, { extensions as propTypeEx } from "tools/prop-types"

class ImageMedia extends React.PureComponent {

  static propTypes = {
    // The `src` property may not be an empty string.
    src: PropTypes.string::propTypeEx.notEmpty().isRequired,
    className: PropTypes.string,
    // If `width` is provided, then `height` is also required, and vice-versa.
    width: PropTypes.number::propTypeEx.dependsOn("height"),
    height: PropTypes.number::propTypeEx.dependsOn("width"),
    // When `fluid` is `true`, both `width` and `height` are required.
    fluid: PropTypes.bool::propTypeEx.dependsOn(["width", "height"]),
    imgRef: PropTypes.oneOfType([
      PropTypes.func,
      // The object must have a `current` property, even if it is set to something nullish.
      // This works differently from `isRequired`, which rejects `null` and `undefined`.
      PropTypes.shape({ current: ExtraTypes.hasOwn })
    ])
  }

  /* (Rest of the class follows...) */
}

Fortunately, the plugin can be configured so that it can recognize them. Unfortunately, Next.js does not expose a means of configuring this plugin.

Describe the solution you'd like

I would appreciate it if the next/babel preset supported configuring the transform-react-remove-prop-types plugin through its options.

An example usage of the .babelrc file:

{
  "presets": [
    [
      "next/babel",
      {
        "transform-react-remove-prop-types": {
          "additionalLibraries": ["tools/prop-types", "tools/extensions/prop-types"]
        }
      }
    ]
  ]
}

Additionally, this could be considered a means of implementing issue #4488, since the ignoreFilenames option could also be configured when a developer deems it useful to do so.

It may not be a bad idea to raise a warning when this option is detected, though.

[Timer]

Hi @JHawkley!

PropTypes are generally not recommended because there are more sound type checking solutions, i.e. TypeScript or Flow.

I'm not sure allowing this to be configured is a good idea, given it would encourage the usage of PropTypes over static types.

[JHawkley]

And I can't argue against that; static-typing is superior. Unfortunately, I'm not currently able to use either of those languages at this time.

I think it's inappropriate to make a presumption like this without taking into consideration the wide variety of configurations a developer may end up needing to work in.

It may be recommended to use static-typing through one of these languages, but the reality of software development is more complex than that. You just don't always get to have the ideal. If prop-types are the best thing available to get _some_ kind of type-safety in a project, it is a good idea to support it.

Besides, having some form of type-safety is better than none at all.

Prop-types are officially supported in both React and Next.js (by its mere inclusion of the transform-react-remove-prop-types plugin) and it does not appear that their usage has been deprecated by either project. If Next.js intends to continue to include this plugin in its Babel preset, it may as well give it first-class support.

Otherwise, removing the plugin from the preset and letting the developer add it back in to their .babelrc file with whatever configuration they require would also be a viable alternative.