Unpin dependencies

[richardsimko]

Describe the Bug

I tried to find some previous discussions about why the dependencies are pinned but could only find this unanswered question: #921

It's generally considered bad practice to pin dependencies in libraries, pinning dependencies should be done by the consumer. There are a few reasons for this:

1. Duplication (As mentioned in the thread), multiple different minor or patch versions of a transitive dependency might (will) need to be installed, slowing down install times
2. Security updates should be decoupled from dependency releases. See for example react-email depends on a vulnerable version of esbuild #1962, NPM dependency vulnerability (moderate)—react-email >=3.0.4 depends on vulnerable versions of next #1856, react-email depends on vulnerable version of next (15.1.2) #2025, chore(deps): bump next from 15.0.4 to 15.2.3 in /examples/resend #1966 and several others. In our project we currently have 3 open Dependabot alerts, all are because of react-email and all could had been fixed with an updated lockfile if the dependencies of react-email were more permissive (Minor or patch version updates). Instead we have to wait for react-email to update these.

Looking through our list of dependencies (About 150) react-email is one of just 3 that have pinned dependencies.

Which package is affected (leave empty if unsure)

react-email

Link to the code that reproduces this issue

N/A

To Reproduce

N/A

Expected Behavior

Unpinned dependencies with ^ (Or at least ~) so that consumers can update minor and patch versions while keeping devDependencies pinned.

What's your node version? (if relevant)

No response

[CHC383]

A few more examples of prettier version conflicts that lead to consumer side's failure

• Prettier external package warning #1993
• Prettier warning in console #1910

[CHC383]

BTW even the most recent react-email v4 release (a month after the last v3 release) didn't include the merged security fix #1904 and #1949, so I think it is better to unpin the dependencies to decouple the the security updates from the release, and relieve the maintenance burden from the react-email team.

[gabrielmfern]

Good points yeah, I think we'll do this. Will discuss with the team