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
Spinning out of #5090: @orgads noted that the package.json versions of dependencies are all pinned to specific versions like 4.1.1 rather than "caret" ^ ranges like ^4.1.1:
I'm accustomed to ^ ranges to help consumers deduplicate packages. E.g. if a consumer's package requirements are chokidar@^3.5.2 and chokidar@^3.6.0, us specifying chokidar@^3.5.3 would mean they could all resolve to the same package version.
The text was updated successfully, but these errors were encountered:
I'm a big 馃憤 to this. It was different in the pre-package-lock.json era, that's when it was good practice to try and lock down dependencies this way, now its better handled by the package-lock.json in our and other's projects.
Maybe implement this on a dependency by dependency basis when we update them? That way we will test that no breakage will occur
Spinning out of #5090: @orgads noted that the
package.json
versions ofdependencies
are all pinned to specific versions like4.1.1
rather than "caret"^
ranges like^4.1.1
:mocha/package.json
Lines 53 to 56 in 3345eff
Why is that?
I'm accustomed to
^
ranges to help consumers deduplicate packages. E.g. if a consumer's package requirements arechokidar@^3.5.2
andchokidar@^3.6.0
, us specifyingchokidar@^3.5.3
would mean they could all resolve to the same package version.The text was updated successfully, but these errors were encountered: