deps!: remove `prop-types` package
Since the project fully leverages TypeScript for type checking, the prop-types package is no longer necessary. Removing it eliminates redundant runtime validation while reducing bundle size. Although this means losing runtime prop validation, TypeScript’s static type checking ensures type safety during development, making this a reasonable trade-off.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 100.00%. Comparing base (
75ccb72) to head (6168aeb).
Additional details and impacted files
@@ Coverage Diff @@
## main #125 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 1 1
Lines 75 74 -1
Branches 9 9
=========================================
- Hits 75 74 -1
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Although this means losing runtime prop validation, TypeScript’s static type checking ensures type safety during development, making this a reasonable trade-off.
Unfortunately, not all users use TypeScript, so we cannot make the assumption that they have static type safety during development 😕
That being said, since React officially archived prop-types and removed support in React 19, I do think we should remove it eventually as well. It is a breaking change though (removing a feature) and react-signature-canvas is still backward-compatible with React 14, so this would only occur in a future breaking major release.
Per https://github.com/agilgur5/react-signature-canvas/pull/116#issuecomment-2569848572, I was looking at making a breaking change to use the newer JSX transform. Per the v1.1.0-alpha.1 release notes, I was also looking to make a breaking change to drop CJS/UMD support.
The newer JSX transform requires a React bump, but not all the way to 19, so I can't say right now if that would be an appropriate time to drop prop-types. They don't add altogether too much, but they also don't harm and can be automatically stripped during production builds, and this library has never had breaking changes before, so I would probably lean toward leaving them in longer as such.
Summarizing, I don't think now is quite the right time for this change, especially with v1.1.0-alpha.1 having recently released and not being v1.1.0 stable yet. Perhaps later this year, but maybe even later than that.