When whisper was being started in a new process, the message displayed in the console was “Starting Blockchain node in another process”. This is misleading as it is the same message that geth/parity use to start up their processes.
Update whisper initialisation process messaging so it states “Starting Whisper node in another process”.
When `eth_unsubscribe` is received in the proxy, ensure this request is forwarded through on the correct socket (the same socket that was used for the corresponding `eth_subscribe`).
Move subscription handling for `eth_subscribe` and `eth_unsubscribe` to RpcModifiers (in `rpc-manager` package).
For each `eth_subscribe` request, a new `RequestManager` is created. Since the endpoint property on the proxy class was updated to be a provider, the same provider was being assigned to each new `RequestManager` and thus creating multiple event handlers for each subscription created. To circumvent this, we are now creating a new provider for each `RequestManager`.
Co-authored-by: Pascal Precht <pascal.precht@googlemail.com>
This PR adds support for EIP-712 (https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md), by allowing the signing of typed data transactions using the `eth_signTypeData_v3` or `eth_signTypedData` request.
Add a module called `embark-rpc-manager` to handle all RPC transaction modifications.
The internal events management module extracted to `embark-core`. This allows other modules (ie plugins) to use a private instance of Embark’s event API.
Remove transaction modifications in `embark-accounts-manager` and leave only the functionality in this module that handle account management (ie funding of accounts). Other functionality was moved to `embark-rpc-manager`.
- Transactions should now reflect when a new node account is added via `personal_newAccount` or via the node itself (and once `eth_accounts` is requested).
- In the proxy, errors are handled for all cases and are now JSON-RPC spec-compliant.
- Always register `eth_signTypedData` RPC response and display error message if account cannot be found.
NOTE: Updated yarn.lock due to conflict after rebase.
Avoid race condition with rpc modifications
Refactor proxy to make request handling asynchronous, and to allow circumvention of forwarding requests to the node in cases where it is not needed.
Move loading of plugins to after core and stack components (in cmd_controller).
We should load custom plugins LAST (ie after all core and stack components, and after all Embark plugins). To do this, we disable automatic loading of plugins in the config, and allow them to be loading explicitly in cmd_controller.
Create a system that allows registration of custom plugins. Each plugin is generated in EmbarkJS by instantiating the registered class. For example, we can register a Plasma plugin and it will be generated in to EmbarkJS.Plasma with an instantiation of `embarkjs-plasma`. The DApp itself can then do what it wants with `EmbarkJS.Plasma` (ie call `EmbarkJS.Plasma.init()`.
NOTE: loading of custom plugins needs to be applied to all other commands in `cmd_controller`. This PR only loads custom plugins for the `run` command.
NOTE: This PR is based on branch fix/ws-eth-subscribe (#1850). I will rebase this PR when (and if) #1850 is merged.
BREAKING CHANGE:
Related to #1985. Prior to Embark's minimum supported version of Node.js being
bumped to to 10.17.0, Embark was incompatible with any relatively recent
release of the `ipfs-http-client` package.
While *internal* changes are needed re: ipfs's `Buffer` export for
e.g. `embark_demo` to function correctly *(and this PR makes those changes)*,
Embark otherwise runs/tests okay.
Keep in mind #2033.
However, if a dApp author were to explicitly `require('ifps-api')` in the
front-end that wouldn't work as before; and swapping `"ipfs-http-client"` for
`"ipfs-api"` might also not be enough — there are API changes that dApp authors
would need to consider, regardless of Embark presently supplying the dependency
and EmbarkJS wrapping around it.
Closes#1994.
Hook `embark-profiler` into the engine's contracts group.
Adjust `request` signatures to match v5 usage.
Ensure gas numbers are formatted consistently in the ascii table.
Display non-json output in cockpit's console as monospace/pre to preserve
profiler table formatting.
The blockchain module should not contain any ethereum-specific code, and currently it contains a check to see if the blockchain has already been started.
This PR moves this check to blockchain client (ie geth or parity). This check function is registered along with the started callback.
style(@embark/stack/blockchain): add missing semicolon
Turns out that, when Embark tries to replace ENS subdomains, it would fail
if `subdomains` aren't defined in the namesystem configuration.
This commit adds a safeguard so that not defining `subdomains` is fine.
This commit fixes the issue that it wasn't possible anymore to use named constructor arguments
in Smart Contract configurations.
For example, the following Smart Contract expects two constructor arguments:
```solidity
contract SomeContract {
constructor(address[] _addresses, int initialValue) public {}
}
```
The first being a list of addresses, the second one a number. This can be configured as:
```js
SomeContract: {
args: [
["$MyToken2", "$SimpleStorage"],
123
]
}
```
Notice how the order of arguments matters here. `_addresses` come first in the constructor,
so they have to be defined first in the configuration as well.
Another way to configure this is using named arguments, which is what's broken prior to this commit:
```js
SomeContract: {
args: {
initialValue: 123,
_addresses: ["$MyToken2", "$SimpleStorage"]
}
}
```
Using a notation like this ^ the order no longer matters as Embark will figure out the right
values for the constructor arguments by their names.
The reason this is broken is because there are several modules in Embark that register and
run a `deployment:contract:beforeDeploy` action, which are allowed to mutate this configuration
object. One of those modules is the `ens` module, which searches for ENS names in the arguments
and figure out whether it has to replace it with a resolved address.
One thing that particular module didn't take into account is that `args` could be either and
array, or an object and will always return an array, changing the shape of `args` in case it was
an object.
This is a problem because another module, `ethereum-blockchain-client`, another action is registered
that takes this mutated object in `determineArguments()` and ensure that, if `args` is actually an
object, the values are put in the correct position matching the constructor of the Smart Contract in
question.
One way to solve this was to use the newly introduced [priority](https://github.com/embark-framework/embark/pull/2031) and ensure
that `ens` action is executed after `ethereum-blockchain-client`'s.
However, the actual bug here is that the ENS module changes the shape of `args` in the first place,
so this commit ensures that it preserves it.
The `WhisperGethClient` returns empty strings for its "new account" and "list
accounts" commands; if a command is an empty string then `Blockchain` should
not execute it.
* fix(@embark/solidity): fix solidity ipc connection with blockchain
When blockchain was run in another process, the IPC was connected,
but the compiler was not loaded, so the IPC calls never returned
* fix(@embark/geth): fix cb is not a fn because it needs request2
We've introduced a regression in https://github.com/embark-framework/embark/commit/f9557d4c9 where invalid data
has been sent to web3's `ecRecover()` method to verify signed messages.
This causes an internal server error and the utility feature inside Cockpit
unsuable.
This commit ensures that the correct data is sent to `ecRecover()` making verifying
messages through Cockpit functional again.
When making use of the `useBuiltIns: 'usage'` option for @babel/preset-env
(which is the case for all transpiled packages in Embark's monorepo) a package
needs to have both @babel/runtime-corejs3 and core-js@3 specified as
dependencies.
* build(deps): move @types/os-locale from packages/embark to packages/core/i18n
* build(deps) move @types/globule from packages/embark to packages/plugins/coverage
* build(deps): refactor stack/{api,proxy,webserver} deps relative to packages/embark
* build(deps): remove unneeded @types/async dep from packages/stack/test-runner
* build(deps): remove unneeded deps from packages/embark
BREAKING CHANGE:
node: >=10.17.0 <12.0.0
npm: >=6.11.3
yarn: >=1.19.1
node v10.17.0 is the latest in the 10.x series and is still in the Active LTS
lifecycle. Embark is still not compatible with node's 12.x and 13.x
series (because of some dependencies), otherwise it would probably make sense
to bump our minimum supported node version all the way to the most recent 12.x
release.
npm v6.11.3 is the version that's bundled with node v10.17.0.
yarn v1.19.1 is the most recent version as of the time node v10.17.0 was
released.
* refactor(@embark/dapps/tests/app): use function syntax
These changes don't fix the race conditions related to the test dapp's tests
but are a step in the right direction.
* refactor(@embark/dapps/tests/contracts): adjustments to get tests passing
Further refactoring is needed re: potentially duplicated or overlapping logic
in `packages/plugins/solidity-tests` and
`packages/core/utils/src/solidity/remapImports.ts`, as well in disabled test
dapp tests
* test(dapps/tests/app): temporarily disable intermittently failing tests
They are failing because of a race condition; once that race condition has been
fixed these tests should be reenabled.
* fix(@embark/solidity-tests): fix importing the library for the tests
* build(@embark/stack/blockchain-client): remove unneeded typescript related scripts and deps
In addition to being unneeded their presence is causing build errors.
* build(embark): remove unneeded typescript related scripts and deps
In addition to being unneeded their presence is causing build errors.
* build(@embark/plugins/ethereum-blockchain-client): remove unneeded typescript related scripts, deps
In addition to being unneeded their presence is causing build errors.
* build(@embark/plugins/ganache): remove unneeded typescript related scripts and deps
In addition to being unneeded their presence is causing build errors.
* build(@embark/plugins/geth): remove unneeded typescript related scripts and deps
In addition to being unneeded their presence is causing build errors.
* fix(@embark/plugins/transaction-logger): require 'web3' not 'Web3'
* fix(@embark/utils/solo): spawn npm(.cmd) instead of npx(.cmd)
* test(@embark/plugins/basic-pipeline): add test stub
* test(@embark/stack/blockchain): add test stub
Fix a lot of bugs and reenable a couple of modules
Some tests were kept disabled, mostly the ENS and EmbarkJS tests
Those need to add back a fairly significant feature to work
Add back missing solidity contracts
* fix: fix tests hanging because the console is not started
* fix(@embark/proxy): send back errors correctly to the client
Code originally by @emizzle and fixed by me
* feat(@embark/test-runner): add assert.reverts to test reverts
* fix: make test app actually run its test and not hang
* fix(@embark/proxy): fix listening to contract event in the proxy
* feat(@embark/test-runner): add assertion for events being triggered
* docs(@embark/site): add docs for the new assert functions
* feat(@embark/test-runner): add increaseTime util function to globals
* docs(@embark/site): add docs for increaseTime
Contains bug fixes to get parity to work as a blockchain client.
**NOTE:** Please merge https://github.com/embark-framework/embark/pull/1950 first before merging this PR, as this PR contains removal of dependencies from `packages/embark` that are needed for geth. So if this is merged first, and the geth PR (https://github.com/embark-framework/embark/pull/1950) is not merged, then geth will not have some of the dependencies it needs.
**NOTE:** Running a dapp with `client: “vm”` does not work, however I am not sure if that is intentional in v5 or not.
**NOTE:** Running `embark test` in the demo DApp does work, although there is an error that I am assuming does actually pertain to this PR:
```
made request without listener: whisper:node:register
Trace:
at EmbarkEmitter.trace [as request] (/Users/emizzle/Code/__Github/embk-fw/embark/packages/embark/src/lib/core/events.js:142:13)
at new request (/Users/emizzle/Code/__Github/embk-fw/embark/packages/embark/src/lib/modules/geth/index.js:49:17)
at Plugin.loadInternalPlugin (/Users/emizzle/Code/__Github/embk-fw/embark/packages/embark/src/lib/core/plugin.js:117:10)
at Plugins.loadInternalPlugin (/Users/emizzle/Code/__Github/embk-fw/embark/packages/embark/src/lib/core/plugins.js:96:40)
at Engine.loadInternalPlugin [as registerModule] (/Users/emizzle/Code/__Github/embk-fw/embark/packages/embark/src/lib/core/engine.js:69:18)
at Engine.registerModule [as blockchainComponents] (/Users/emizzle/Code/__Github/embk-fw/embark/packages/embark/src/lib/core/engine.js:183:10)
at Engine.apply [as registerModuleGroup] (/Users/emizzle/Code/__Github/embk-fw/embark/packages/embark/src/lib/core/engine.js:104:18)
at registerModuleGroup (/Users/emizzle/Code/__Github/embk-fw/embark/packages/embark/src/cmd/cmd_controller.js:740:16)
at nextTask (/Users/emizzle/Code/__Github/embk-fw/embark/node_modules/async/dist/async.js:5324:14)
at next (/Users/emizzle/Code/__Github/embk-fw/embark/node_modules/async/dist/async.js:5331:9)
at /Users/emizzle/Code/__Github/embk-fw/embark/node_modules/async/dist/async.js:969:16
at callback (/Users/emizzle/Code/__Github/embk-fw/embark/packages/embark/src/lib/core/engine.js:47:9)
at Client.done (/Users/emizzle/Code/__Github/embk-fw/embark/packages/core/core/src/ipc.js:46:11)
at Client.emit (/Users/emizzle/Code/__Github/embk-fw/embark/node_modules/event-pubsub/es5.js:74:21)
at Socket.connectionClosed (/Users/emizzle/Code/__Github/embk-fw/embark/node_modules/node-ipc/dao/client.js:201:20)
at Socket.emit (events.js:198:13)
```
**TODO:** The `embark eject-webpack` command needs to be updated. @michaelsbradleyjr - do you have suggestions as to how we could port this over? We could **assume** that the `basic-pipeline` plugin will be installed, and then read the embark config and overrides from the file system, however this feels like we are sort adding a dependency to a plugin, which is not right. Any suggestions?
It's principal use was in `stack/compiler`, but that package was refactored
in #1878 to use async/await. There was a replica in
`packages/embark/src/lib/utils/async_extend.js` but it wasn't being used to do
async operations and could be replaced with `Object.entries().forEach()`. It
was required by `plugins/vyper` but the wrapper's custom `eachObject` method
wasn't being used. `stack/api` had it as a dependency but wasn't using it.
When an options object is not supplied the tests fail because the constructor
expects the options argument to be an object, i.e. referencing
`options.plugins` should not cause a TypeError
* chore(@embark/): move embarkjs packages to their own folder
* chore(@embark/): rename embark-ui folder to cockpit
* chore(@embark/): rename packages already in logical folders to remove embark- prefix
chore(@embark/): rename packages already in logical folders to remove embark- prefix
update package.json files to use correct eslint config
remove core/* from package.json workspaces
dependabot-preview[bot]
Michael Bradley, Jr
Jonathan Rainville
emizzle
Pascal Precht
Iuri Matias
André Medeiros