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
Currently, I believe our [patch] table support is limited to individual packages (@kayagokalp correct me if I'm wrong 😅).
We should match Rust's behaviour, where [patch] is applied at the workspace level. This is because the workspace is responsible for the overall package graph and lock file, and when a patch needs to be applied to a package in the graph it is most often applicable for all members of the workspace.
The text was updated successfully, but these errors were encountered:
This is definitely a must-have! While testing things with huge workspaces (the latest incident was SDK's testing suite workspace 😄) I find myself going in each Forc.toml and adding an explicit std dependency so that I can build with master forc.
## Description
closes#3958.
This is a handy feature for tests with workspaces. We were already
supporting a `patch` table feature for packages. This PR adds the same
feature for workspaces. Basically we can patch every instance of a
package with a different version. One main motivation behind this can be
patching the standard library while working with an unreleased version
of `forc`. With this feature we can pin the `std` version for the whole
workspace so that all members in the workspace depending on `std` would
depend on master version of the `std`.
Currently, I believe our
[patch]
table support is limited to individual packages (@kayagokalp correct me if I'm wrong 😅).We should match Rust's behaviour, where
[patch]
is applied at the workspace level. This is because the workspace is responsible for the overall package graph and lock file, and when a patch needs to be applied to a package in the graph it is most often applicable for all members of the workspace.The text was updated successfully, but these errors were encountered: