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
The example I think shows something being moved or replaced with a "compatible" successor, would this also apply to moving between dependencies that are not directly related? For example, transitioning from Bootstrap to Material for the UI? In that case it seems like a semver range spec, at least on the successor, would help ensure that people get the latest or an otherwise desirable range (i.e., if there's a known bug with the way a specific version interacts with another dependency).
It'd also be good to have support for dependencies getting "split" into multiple packages. For example, if dependency A has features 1, 2 and 3 at v1.0, and 3 gets removed for v2.0 and moved into dependency B, the successor to the deprecated [email protected] might be both [email protected] and [email protected].
We need a way to enforcing migrating away from deprecated packages.
For instance, ensuring folks move from
rollup-plugin-babel
to@rollup/plugin-babel
Need to look into if there’s a native npm/yarn signal that a package is deprecated or if this is something that needs to be configured.
The text was updated successfully, but these errors were encountered: