The prop-types npm package is a small runtime type-checking library that React extracted into a standalone package back in 2017, and as of React 19 the framework no longer reads propTypes internally, so its role is shrinking to legacy support and non-React consumers. From a security standpoint it is a low-risk, narrow-purpose dependency, but the React 19 change is a good reason to reassess whether you still need it and how it sits in your supply chain.
React originally shipped React.PropTypes inside the core library. It was deprecated in April 2017 with React 15.5.0 and moved into its own prop-types package so React could stop carrying it. For years that was the standard way to declare and validate component props at runtime in development.
What prop-types does
The package validates the shape of values at runtime and, in development builds, logs a console warning when a prop does not match its declared type. It never throws in production and never changes behavior; it only warns. That makes it a developer-experience tool wearing the clothes of a type system.
import PropTypes from 'prop-types';
function Greeting({ name, count }) {
return <h1>{name}: {count}</h1>;
}
Greeting.propTypes = {
name: PropTypes.string.isRequired,
count: PropTypes.number,
};
If count arrives as a string, you get a console warning in development. In production the check is stripped, so there is no performance cost and no runtime enforcement.
The React 19 change
This is the fact worth internalizing. In React 19, the framework stopped reading the propTypes property on components. Assigning Component.propTypes is now silently ignored by React itself, so the warnings you relied on will not appear unless something else is invoking the validators. The React team's guidance is to migrate to TypeScript or another static type-checking approach.
The prop-types package still exists and is still published; it was not deleted. What changed is that React no longer calls into it automatically. If you upgrade to React 19 and keep your propTypes declarations, they become dead documentation that no longer validates anything at runtime. That is a correctness and clarity issue more than a security one, but it is the reason to revisit the dependency now.
Security posture
As a dependency, prop-types is about as benign as they come. It is small, has a long track record, is maintained under the community-run ljharb tooling org, and does exactly one thing. It does not touch the network, the filesystem, or any credentials. There is no history of it being a notable attack vector.
That said, "benign" does not mean "ignore." Every dependency is part of your attack surface through the supply chain, not just through its own code. The realistic risks with a package like this are:
- A compromised release. Any popular npm package is a target for account takeover or a malicious publish. Pin the version and verify integrity hashes in your lockfile so an unexpected republish does not slip in.
- Abandonment drift. A package that stops being maintained accumulates vulnerable transitive dependencies over time. prop-types has few dependencies, so this risk is low, but it is the general reason to track maintenance status.
- Dead weight. Shipping a checker that React no longer invokes adds bytes and cognitive load for no benefit. Removing unused dependencies shrinks the surface you have to reason about.
A scanner that watches your lockfile, such as Safeguard's SCA, will tell you if any version in your tree, including small utilities like this one, carries a known advisory. That is more reliable than manually tracking dozens of minor packages.
Should you keep using it?
The decision splits cleanly by context.
If you are on React 19 or moving there, plan to migrate off runtime propTypes toward TypeScript or a static checker. Static typing catches mistakes at build time, across production and development equally, which propTypes never did. There are codemods to help remove propTypes declarations once you have real static types.
If you are on an older React that still honors propTypes, and you are not ready to adopt TypeScript, keeping prop-types is a reasonable interim. It is cheap and it does give you real development-time feedback. Just recognize it as a stopgap, not a destination.
If you maintain a non-React library that happens to use prop-types for its own validation, nothing changes; the package works independently of React and you can continue using it directly.
Removing it cleanly
When you do drop it, remove both the import and the .propTypes assignments; leaving the assignments without the runtime library will not error but is confusing. Search for PropTypes across the codebase, replace the intent with TypeScript interfaces or prop types, then uninstall:
npm uninstall prop-types
Run your type checker and test suite afterward to confirm you did not lose coverage you were quietly depending on. The same disciplined approach to trimming dependencies applies to any package, and it pairs well with the secure-by-default habit of keeping the shipped footprint minimal.
FAQ
Is prop-types deprecated?
The runtime propTypes mechanism inside React is effectively retired: React 19 ignores it. The standalone prop-types npm package is not deleted and still works as an independent validator, but the React team recommends migrating to static type checking like TypeScript.
Does React 19 break my prop-types code?
It does not throw errors, but it stops honoring Component.propTypes, so your declarations no longer produce validation warnings. They become inert. Nothing crashes, but you lose the checks silently, which is the argument for migrating to a static type system.
Is the prop-types package a security risk?
On its own it is very low risk: small, focused, no network or filesystem access, and well established. The realistic concerns are supply-chain generic ones, a compromised publish or abandonment drift, which you mitigate by pinning versions, verifying lockfile hashes, and scanning your dependency tree.
What should replace prop-types?
TypeScript is the standard replacement, giving you type checking at build time across all environments. Where TypeScript is not an option, other static analysis or JSDoc-based typing can fill part of the gap. The goal is to move validation from development-only runtime warnings to compile-time guarantees.