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
We should decide which parts of buidler will be compatible with truffle, and why.
My current idea is that buidler should only be compatible enough to make migration from Truffle very easy. I think this is specially important for contracts' tests, which nobody will want to rewrite just to use another tool.
buidler test now runs truffle-compatible tests, but that ties us to Truffle-contracts, or at least to its APIs. We should consider making explicit what's truffle-compatibility and whats native in buidler, like making those tests runnable with buidler truffle-test, or even create a buidler-truffle plugin.
We also implemented their networks configuration system, which is very focused on web3. Specially the provider field is normally used along web3-provider-engine, which we want to avoid and may block #5.
The text was updated successfully, but these errors were encountered:
After the change that moved MiningTimer to HardhatNetworkProvider, interval mining acquires the mutex in require method. As a result, it's sufficient to call and await on any provider method after ticking the sinon clock. They will simply wait on mutex for the mine function to finish.
We should decide which parts of buidler will be compatible with truffle, and why.
My current idea is that buidler should only be compatible enough to make migration from Truffle very easy. I think this is specially important for contracts' tests, which nobody will want to rewrite just to use another tool.
buidler test
now runs truffle-compatible tests, but that ties us to Truffle-contracts, or at least to its APIs. We should consider making explicit what's truffle-compatibility and whats native in buidler, like making those tests runnable withbuidler truffle-test
, or even create abuidler-truffle
plugin.We also implemented their networks configuration system, which is very focused on web3. Specially the
provider
field is normally used alongweb3-provider-engine
, which we want to avoid and may block #5.The text was updated successfully, but these errors were encountered: