This commit introduces a new `global.getEvmVersion()` that can be used to
conditionally run tests, such as when tests rely on RPC APIs that are only
available in specific evm nodes.
When running tests that expect the EVM to fail, Embark's proxy keeps logging
the VM errors to stdout making it look like tests weren't successful, while they
are actually passing.
Inside a test-runner it's probably expected not to see any error logs when the
tests in question expect errors.
This commit changes the proxy to use `debug()` logs instead of `error()`, making
it configurable through log verbosity how much errors are seen.
## Issue
Transaction logs for contracts that were unknown to Embark (ie not in the dapp) would often log super large objects (filling the terminal) that were not formatted with spaces so were hard to read without actually be that useful. In addition, occasionally the object logged would throw the error `TypeError: Converting circular structure to JSON`.
## Fix
Set the log level for transaction logs that are not from a known contract to `debug`, so that they do not flood the terminal with often usused information.
Use `util.inspect` to print the transaction log instead of `JSON.stringify` to prevent circular structure errors.
The problem was that putting the artifacts in src caused them to be watched
and thus creating an infinite loop, because a change in src triggers the build of the artifacts
This was fixed by ignoring the artifacts by chokidar, wherever they are
If using `embark-snark` in the dapp as a plugin, and the dapp didn’t have any contracts, the `embark-snark` plugin would not simply exit early and essentially do nothing.
Fix `embark-snark` plugin so that it will run its routine regardless of whether or not the dapp has contracts or not.
Bump `circom` and `snarkjs` to their latest patch version.
## Issue 1 - “register” section missing
When the “register” section of `namesystem.json` was missing, ENS would not deploy the ENS contracts nor create the contracts’ artifacts.
### Fix 1
Fix ENS deployment routine to always deploy the ENS contracts. In the case of testnet/mainnet, the contracts’ addresses will be known and therefore will be understood as “already deployed” by the contract deployer.
## Issue 2 - “register” section exists for non-dev environment
Additionally, if a root domain was specified in the “register” section and the DApp connected to an external node where we do not own the ENS contracts (ie testnet), attempting to register a root domain would not be possible as we do not own the ENS contracts.
### Fix 2
Fix ENS deployment routine to check if we are on a network in which we own the ENS contracts. If we are not, and we have specified a “register” section, print a warning to the user that the registration will be ignored. Additionally, remove the “register” section.
The transaction-logger was slowing down tests because each Tx, it
would read a file and write to it, but that's slow and even got
slower as the file grew bigger
To fix, I removed the Tx-logger from text, along with the profiler
as they are useless for tests
(cherry picked from commit a656eea7dda83ad970615cffd51cce5d53a1d034)
There was a race condition in which the coverage module tried to read a generated
coverage report before it was actually generated.
The issue was that the coverage generation was done on Embark's `tests:finished` event
in a fire and forget manner via `emit('tests:finished')` which doesn't
ensure control flow.
This commit changes it to use `runActionsForEvent('tests:finished')` instead and also
registers the handler for coverage report generation as action via `registerActionForEvent()`.
This ensures that those actions are run first, before the code moves on with other
operations that might rely on the result of any of those actions.
Refactor typings as necessary. In order for `bignumber.js` in the root
`node_modules` to not conflict with `@types/bignumber.js`, specify
`"bignumber.js": "5.0.0"` in `devDependencies` and `"embark-ui/bignumber.js"`
in `nohoist` of the root `package.json`.
In `packages/plugins/rpc-manager` switch from callback to promise usage with
respect to `web3.eth.accounts.signTransaction` because of a [bug][bug]
discovered in web3 v1.2.4.
In `packages/plugins/solidity-tests` specialize the tsc compiler options with
`"skipLibCheck": true` because of a problematic web3-related typing in the
`.d.ts` files of the remix-tests package.
Bump ganache-cli from 6.4.3 to 6.7.0 (latest) because 6.4.3 doesn't support
`eth_chainId` but web3 1.2.4 makes use of the `eth_chainId` RPC method (EIP
695).
BREAKING CHANGE: bump embark's minimum supported version of parity from
`>=2.0.0` to `>=2.2.1`. This is necessary since web3 1.2.4 makes use of the
`eth_chainId` RPC method (EIP 695) and that parity version is the earliest one
to implement it.
[bug]: https://github.com/ethereum/web3.js/issues/3283
Was caused by the fact that each rpc-modifier got its own node
accounts, but once the eth_accounts modifier is enabled, the
"node" accounts are always going to contain the custom accounts too
Now, the node accounts are set once eth_accounts is initiated, so
that every modifier is on the same page
Also implement a second layer of protection to make sure that if a
duplication happens, it is gotten rid of
For the test DApp, when ENS is enabled, ENS controls were not showing in Cockpit (under Utils), nor were they available to test in the DApp interface as they did not exist.
Fix ENS controls not showing in Cockpit when enabled.
Add ENS tab to Test DApp for ENS UI.
During `embark test`, the contracts dapp was throwing an error:
```
connection not open on send()
Error: Invalid JSON RPC response: ""
at Object.InvalidResponse (/Users/michael/repos/embark/node_modules/web3-core-helpers/src/errors.js:42:16)
at XMLHttpRequest.request.onreadystatechange (/Users/michael/repos/embark/node_modules/web3-providers-http/src/index.js:92:32)
at XMLHttpRequestEventTarget.dispatchEvent (/Users/michael/repos/embark/node_modules/xhr2-cookies/xml-http-request-event-target.ts:44:13)
at XMLHttpRequest._setReadyState (/Users/michael/repos/embark/node_modules/xhr2-cookies/xml-http-request.ts:219:8)
at XMLHttpRequest._onHttpRequestError (/Users/michael/repos/embark/node_modules/xhr2-cookies/xml-http-request.ts:379:8)
at ClientRequest.<anonymous> (/Users/michael/repos/embark/node_modules/xhr2-cookies/xml-http-request.ts:266:37)
at ClientRequest.emit (events.js:198:13)
at Socket.socketErrorListener (_http_client.js:392:9)
at Socket.emit (events.js:198:13)
at emitErrorNT (internal/streams/destroy.js:91:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
at process._tickCallback (internal/process/next_tick.js:63:19)
(node:75120) UnhandledPromiseRejectionWarning: Error: Provider not set or invalid
...
```
This was due to the fact that during testing, the Ganache VM **provider** is used as the blockchain node, instead of spinning up an instance of Ganache. Due to this, there is no HTTP nor WebSockets RPC endpoint opened on the VM node, and the contracts dapp was not able to connect to the node during tests.
Add `$EMBARK` to the contract config’s `dappConnection` list, so that the contract test dapp can successfully connect to Embark’s proxy, which ultimately communicates with the Ganache VM.
As a side note, without `$EMBARK` in the `dappConnection` list, the tests could run successfully when using `embark test —node=embark`. This succeeds because the geth node exposes the RPC WebSockets endpoint that the contracts app connects to on `ws://localhost:8546`.
This fixes a bug that redeployment of contracts has not been properly
reflected in the cockpit contract list.
The reason for that was that it's listening for a websocket API that
only updates when the `contractsState` event has been emitted.
The commit ensures `contractsState` is emitted during dedicated deployment
events.
Since ee56f37713, any deployment hook that
was using simple `console.log()` statements to output information, would result in
unexpected `[[object object], [object object]]`.
Unfortunately, the reason for that was that we switched from non-arrow functions to
arrow functions [here](ee56f37713 (diff-a7c4cef8bfebeb39fcd092aca5570fecL324-L340)). Usually switching from non-arrow functions to arrow functions solves
a lot of lexical scope issues where the current reference of `this` isn't pointing at the
right thing.
We're tempering with the global `console.log` inside Embark, which then, combined with
**proper** lexical scope, causes the output described above.
Generally there are a few ways to go about this:
1. Ensure that our custom log functions doesn't turn every log statement into an array output
2. Tell users not to use `console.log` inside deployment hooks and instead rely on `deps.logger`
3. Revert the changes made in the mentioned commit and use non-arrow functions inside `interceptLogs`
Option 2) is not really a solution as we can't simply tell our users that they can't use one of
the most used functions in JavaScript. Option 1) requires finding out why we're formatting logs
by default in an array shapre in the first place. On top of that, we might be relying on this
inside Embark, so it could break certain output.
Option 3) seems to be the most pragmatic solution for now as it doesn't introduce any of the
downsides mentioned above at the cost of using non-arrow functions.
Pascal Precht
emizzle
Bouzaine Chamsddine
Michael Bradley, Jr
Jonathan Rainville
dependabot-preview[bot]
Iuri Matias
Bouzaine chamsddine