You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Avoid pinning versions. It blocks downstream users from receiving bug fixes and security updates until you release a new version containing said updates. It is also a reason for many duplicates and generally known to be de-duping killer.
The risk of downstream users breaking from a 3rd party update is much lower when projects use lock files. And these pinned versions only work for the first level, so 4th party dependencies can still potentially break, rendering the pinning approach useless. imho, it causes more harm than good, and should be used with caution (I usually use it as a temporary workaround, only when breaks occur and when upstream isn't responsive).
Thank you. Your work is much appreciated.
The text was updated successfully, but these errors were encountered:
[REQUIRED] Describe your environment
[REQUIRED] Describe the problem
@firebase/app
(and 11 others) specifiestslib
without a caret in itspackage.json
.When a patch version gets released (like just now), other requests get upgraded, and firebase packages each has a duplicate older version.
Steps to reproduce:
mkdir bug cd bug npm init -y npm i firebase typescript tslib
look in
node_modules/@firebase/*/node_modules/tslib
<--- duplicates! many of them!Relevant Code:
https://github.com/firebase/firebase-js-sdk/blob/master/packages/app/package.json#L36
(and all other package.json files specifying dependencies).
Suggested solution
Avoid pinning versions. It blocks downstream users from receiving bug fixes and security updates until you release a new version containing said updates. It is also a reason for many duplicates and generally known to be de-duping killer.
The risk of downstream users breaking from a 3rd party update is much lower when projects use lock files. And these pinned versions only work for the first level, so 4th party dependencies can still potentially break, rendering the pinning approach useless. imho, it causes more harm than good, and should be used with caution (I usually use it as a temporary workaround, only when breaks occur and when upstream isn't responsive).
Thank you. Your work is much appreciated.
The text was updated successfully, but these errors were encountered: