Those had been removed in a refactor while the Smart Contract sources have been
kept around, resulting in deployment errors as Embark doesn't know what to do
with the Smart Contracts that don't come with a dedicated config.
This commit re-adds the configurations to make the deployment pass again.
Previously, in the embark cli dashboard/console, if you were to type `Foo.` and
hit tab for autocomplete then (assuming you hadn't defined `Foo`) there would
be unhandled errors and the console could even become unusable.
Refactor `packages/core/console` and related code so that nothing happens when
you attempt to autocomplete a bad reference (the same behavior as Node's own
REPL).
Also bump peerDeps: @emotion/core from 0.13.1 to 10.0.22 and @emotion/styled
from 0.10.6 to 10.0.23. Satisfy @babel/runtime peerDep with 7.6.3.
Make small refactors in components/FileExplorer and
containers/FileExplorerRowContainer re: the package upgrades.
Replaces #1998
* 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
As part of the refactor in e330b338ea we've introduced a
second geth client process to enable whisper functionalities in DApps.
This introduced also a new default port for whisper (e330b338ea (diff-a61fbc84e4172487789d676437f26b5fR14)).
This default port has not been introduced on our boilerplate template which is
used in `embark new` when developers scaffold new apps.
This resulted in runtime errors where the geth process for whisper wasn't
able to successfuly boot up as its configured port address is already in use:
```
geth exited with error code 1
geth exited with error code 1
Blockchain process ended before the end of this process. Try running blockchain in a separate process using `$ embark blockchain`. Code: null
```
This commit changes the default port for whisper in the boilerplate template
to ensure apps created using `embark new` don't run into this error anymore.
`embark console` registers and tries to spin up `Cockpit`, even when there's already
a Cockpit instance running and thefore exits with an error that a certain port is already
in use.
This commit ensures that Cockpit is only bootstrapped when `embark console` is
executed as a non-secondary process, meaning that there's no other `embark run`
process active that might occupy Cockpit's default port.
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.
As discussed in #2008, the `service on/off` command in Embark's interactive console
is non-functioning. As solving the root of the problem requires a bit more effort
than anticipated, we've decided offline to remove this command for the time-being.
The functionality is already gone, this commit removes the corresponding docs.
Fix the proxy’s handling of WebSocket connections when subscribing to contract events and node data using the `eth_subscribe` RPC request.
Previously, the client connection that the subscription data was sent to was often in a closed state. It was determined that this connection was the wrong connection to forward the data in the first place. The connection was in fact generally the connection created for the Ethereum service check which was then (correctly and subsequently) closed after it had finished its operation.
The flow of a proxy request handling a WebSocket “eth_subscribe” RPC request is now as follows:
1. A WebSocket RPC request `”eth_subscribe”` is sent from a client to the proxy.
2. Proxy forwards the request to the node by way of a new instance of `RequestManager`.
3. When the node receives an event matching the subscription, it sends the event data back to same socket connection it received the request on (ie the specific instance of `RequestManager`).
4. The `RequestManager` fires the `”data”` event containing the subscription data, and this event is picked up in the proxy.
5. The proxy then forwards the subscription data on to the originating WS client connection.
All other requests (ie non-WS or WS RPC requests that are not `eth_subscribe`) will be serviced to/from the node using a single `RequestManager` instance.
Co-authored-by: Pascal Precht <pascal.precht@gmail.com>
Embark's `yarn.lock` was pointing to es-abstract@1.14.0 but that's problematic
because that version was unpublished (in the allowed time window). Some of the
npm/yarn registry servers/mirrors (and cloudflare's cache) do make that
version's tarball available for download but not all of them, apparently.
* Revert "fix(@embark/core): set loglevel back to info"
This reverts commit a03ffd56e5.
* Revert "fix(@embark/proxy): Fix contract event subscriptions"
This reverts commit 173d53de2f.
Fix the proxy’s handling of WebSocket connections when subscribing to contract events and node data using the `eth_subscribe` RPC request.
Previously, the client connection that the subscription data was sent to was often in a closed state. It was determined that this connection was the wrong connection to forward the data in the first place. The connection was in fact generally the connection created for the Ethereum service check which was then (correctly and subsequently) closed after it had finished its operation.
The flow of a proxy request handling a WebSocket “eth_subscribe” RPC request is now as follows:
1. A WebSocket RPC request `”eth_subscribe”` is sent from a client to the proxy.
2. Proxy forwards the request to the node by way of a new instance of `RequestManager`.
3. When the node receives an event matching the subscription, it sends the event data back to same socket connection it received the request on (ie the specific instance of `RequestManager`).
4. The `RequestManager` fires the `”data”` event containing the subscription data, and this event is picked up in the proxy.
5. The proxy then forwards the subscription data on to the originating WS client connection.
All other requests (ie non-WS or WS RPC requests that are not `eth_subscribe`) will be serviced to/from the node using a single `RequestManager` instance.
Co-authored-by: Pascal Precht <pascal.precht@gmail.com>
Running embark's `blockchain` command resulted in a runtime error where the `blockchain`
module couldn't be found. This is a bug introduced in ed0d3afb4f where
we forgot to update `blockchainStackComponents` in Embark's engine accordingly.
Fixing this results in `embark blockchain` hanging. This is because there's a similar bug
in `blockchainStackCopmnonents` introduced in 3b8f8f9ea7.
This commit fixes both bugs by ensuring `embark-blockchain` and `embark-blockchain-client`
packages are loaded using the correct APIs.
If the version in the embark package's own `package.json` has a prerelease
identifier then appending `.x` to the major version isn't viable for resolving
the latest version of the template package that's in the same prerelease line;
a more complex semver range must be used:
```
"${pkg}@^${major}.${minor}.${patch}- <${major}.${minor}.${patch}"
```
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.
Embark relies on certain specific plugin properties, e.g. registered compilers,
and retrieves them using `plugins.getPluginProperties('compilers', 'compilers')`.
In order to make this work in the testing environment, we need those same APIs
in the `embark-testing` package as well.
This commit adds necessary APIs to `Plugins` and `Plugin` to make registering and
loading compiler plugins work.
* build(deps): move deps needed by embark-basic-pipeline from packages/embark
Introduce additional refactors to ensure the packages can be resolved by the
basic pipeline's webpack child process.
* 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
* build(deps): upgrade create-react-app for cockpit by bumping react-scripts to latest
Also get rid of a peer dependency warning related to storybook. After some
investigation it seems that storybook can't practically (at present) be made
aware of CRA in the same project satisfying storybook's peer deps, so it's best
to just satisfy all of them explicitly, which in any case won't interfere with
CRA (react-scripts).
* 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
dependabot-preview[bot]
Pascal Precht
Michael Bradley, Jr
Jonathan Rainville
Iuri Matias
emizzle