Add notice to the README to let people know PropTypes are no longer the recommended prop validation method

[jharris4]

It would be good to notify people making issues and PRs to this package that it is now considered legacy and no longer actively maintained so they can stop wasting their time (unless new maintainers step up and are giving publish rights of course)

For context, this is from @sebmarkbage at Facebook regarding this package:

We had considered fixing them but instead we moved them out of the core package.
The whole mechanism is considered legacy and not part of core React.
It could be further improved in third party if people find enough value.
The general recommendation is to use TypeScript instead.

(From this twitter thread: https://mobile.twitter.com/sebmarkbage/status/1074736468503842817?s=21)

[MatthewHerbst]

It could be further improved in third party if people find enough value. The general recommendation is to use TypeScript instead.

That does not imply in any way that prop-types is legacy, or that it should not be used. Many people do not, and will not ever, use Typescript. This package being 3rd party maintained does not mean it is legacy.

[jharris4]

Umm, he literally used the word legacy, and recommended using another solution (he mentioned TypeScript but just as well could be Flow). But I'm just the messenger here. PropTypes used to be recommended by Facebook for use with React, and now not so much.

If other maintainers want to step up and start moving it forward great, but at present there hasn't been any activity on this package for quite some time. PRs that people want are sitting open for months with vague promises from the core team "to look at them soon" with no result.

I wasn't advocating that people stop using this package. Just that people be warned that it isn't being actively maintained or given priority by the core React team.

[MatthewHerbst]

Just that people be warned that it isn't being actively maintained or given priority by the core React team.

That's different from "legacy." Legacy implies something is old and not being used/dying. prop-types has 3,774,755 weekly downloads on npm, and seemingly based on the npm chart (which isn't very granular), is growing that number, or at least keeping it stable.

I'm not doubting Facebook's move towards Typescript (or Flow, or ReasonML, or whatever else they decide is next), but "legacy" is a scary word. There's no reason to actively discourage people from using this package if they aren't using TypeScript, which is what a "legacy" warning in the README would do.

Maybe Facebook will put more resources into this, or maybe someone will fork it and that will become the de-facto version to use, but this library is far from legacy, even if it is poorly maintained by Facebook standards.

I do think something along the lines of "we encourage you to use TypeScript or another typed language rather than using this package" would be appropriate.

[jharris4]

Again, I'm using the word legacy as it was straight from the horse's mouth so to speak. It was not my choice of words!

The reason most people (myself included) started using PropTypes is because it was recommended by Facebook. Since they no longer recommend it, then maybe people should be discouraged. Change can be a scary thing at first, but it's not always bad.

At the very least, I'm hoping this issue might draw the attention of some of the core Facebook team and encourage them to finally weigh in rather than leaving this package in a state of limbo...

The choice of wording can be left up to them or others, but saying something would be better than the status quo in my humble opinion.

(Also, the definition of legacy actually does seem to fit particularly well here! denoting or relating to software or hardware that has been superseded but is difficult to replace because of its wide use.)

[MatthewHerbst]

The choice of wording can be left up to them or others, but saying something would be better than the status quo in my humble opinion.

There we can agree!

Since they no longer recommend it, then maybe people should be discouraged.

I would agree if there was a non-TypeScript viable alternative, which currently I don't know of (I know there are many other prop types libraries, but my guess is most use this library as a dependency.)

[ljharb]

Until the official React docs say that propTypes are "legacy", then it's not the case, despite what individuals on the React team may tweet - and once it does, then we certainly should update the readme here. Closing for now.

[adamchenwei]

And yet, so many issue like allowing null in proptype, are still not yet addressed, sad....

[ljharb]

@adamchenwei it's worth noting that the metric for a package being legacy or deprecated isn't "they haven't implemented features i want" :-)

[danielrob]

@ljharb we don't need them to implement the features. Just merge the ones implemented by the community that have 50 thumbs up from the community and basically no downside and have been in the PR queue for 2 years.

I think we've all got hung up on the word legacy, legacy or not legacy is a technicality overlaying the fact that this project appears to be no longer maintained, and that should be made clear.

[ljharb]

@danielrob it's quite maintained - I maintain it. That new features haven't been merged in no way reflects a lack of maintenance, and "implemented by the community" or "has X thumbs up" or "has no downside" don't impact that (the latter two being very subjective - every new feature has an automatic downside of "there's more to maintain")

[danielrob]

@ljharb I see your perspective, and I very much appreciate that you have come on board to maintain this project. With a little more time with you onboard and/or more people aboard, hopefully it would appear more maintained, including evolving further over time. Thank you for your work towards this.