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>
* 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
Introduce some light refactoring related to embark-testing facilities, and also
a configurable stdout option so the output of the reporter implemented in this
package isn't confusingly mixed into unit test reporting for this package.
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
In d6bf5c24b9 we've ensured that certain modules of
embark only executed if their functionality is actually enabled.
This broke one of our tests in the communication module.
This commit fixes the test by explicitly enabling the module's functionality.
* 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?
* bugfix(@embark/embark): fix default values so choosing different environment doesn't cause hang
* bugfix(@embark/stack/watcher): add callback so initializating watcher does not hang cmd controller
Change components/TexEditor re: how monaco-editor is loaded, since difficulties
with monaco-editor were the original motivation for "ejecting" the CRA setup.
Specify "nohoist" for `embark-ui/react-scripts` and all its dependencies to
avoid potential headaches when upgrading the react-scripts, i.e. upgrading to
newer versions of create-react-app.
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.
* chore: test framework
* chore(@embark/testing): introduce Plugin apis and other changes
* refactor(@embark/deployment): use new testing APIs for tests
* feat(@embark/compiler): support :before and :after hooks on event compiler:contracts:compile
* style: keep root package.json sorted cleanly
* style: formatting with prettier where print-width is 200
Per the suggestion of @iurimatias
* WIP: PR review
* WIP: PR review
* WIP: refactor to check if file.path is within dappPath() or os.tmpdir()
* WIP: PR review
* WIP: use native async functions (and related JS lang constructs) instead of the async library
* WIP: async.eachObject is no longer a dependency
* fix: fix test-app, contracts index file and reload on change
* fix(@embark/cmd_controller): fix missing nodes
Was removed by accident
* feat(@embark/demo): add favicon to embark demo
* chore(@embark/cockpit): change favicon to new Embark logo
* fix(@embark/embarkjs-ens): fix ENS config for embarkjs-ens
* remove comments
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
* fix(@embark/cmd_controller): fix embark blockchain command
* feat(@embark/blockchain): ping endpoint before starting the node
also use web3 instead of function to ping endpoint
* dont override console.error completely
* fix embarkjs generation
fix ens setProvider
fix embarkjs objects
fix generated embarkjs provider
generate contracts
fix embarkjs-ens
* address some of the issues in the code review
* feat(@embark/specialconfigs): introduce dynamic addresses
This commit introduces a new Smart Contract configuration addressHandler
that lets users define a function to "lazily" compute the address of the
Smart Contract in question.
This is useful when a third-party takes care of deploying a dependency
Smart Contract, but the address of that Smart Contract only being available
at run-time.
Example:
```
deploy: {
SimpleStorage: {
fromIndex: 0,
args: [100],
},
OtherContract: {
deps: ['SimpleStorage'],
address: async (deps) => {
// use `deps.contracts.SimpleStorage` to determine address
},
abiDefinition: ABI
},
}
```
In the example above, OtherContract will be deployed after SimpleStorage
because it uses the deps property to define Smart Contracts that it depends
on. All dependencies are exposed on the addressHandler function parameter
similar to deployment hooks.
Closes#1690
There was an error that would display on the second+ run of embark, that was causing by trying to read JSON of an empty file.
The solution was a combination of ensuring the file existed with defaults when enabled, and also ensuring we await the saving of the file.
Included is a bit of a refactor of how the tracking functions handled the “current chain”. Hopefully, this should make things more clear.
Tests have been updated accordingly.
* fix embarkjs generation
fix ens setProvider
fix embarkjs objects
fix generated embarkjs provider
generate contracts
fix embarkjs-ens
* address some of the issues in the code review
* address some of the issues in the code review
* address some of the issues in the code review
* address some of the issues in the code review
* refactor(@embark/cmd-controller): re add cargo for file watcher
(cherry picked from commit 5c77b4000742a14f42a6dc5c145672b9cd0957a3)
* use generate:all instea dof the event
This is crucial as the storage module tries to generate/eval artifacts that
depend on a `web3` object inside the VM scope. The registration of that object
can only be garuanteed when the `blockchain:started` event has been fired.
This commit ensures these modules are not spinned up in parallel as we're running
into race conditions.
DApps generated with `new --simple` don't have a blockchain config so ensure
that the blockchain proxy and listener (dev_txs) use appropriate provider
settings when setting up web3.
Without these changes, in a fresh `embark new --simple` project the `embark
blockchain` command will encounter unhandled promise rejection with respect to
the proxy; `embark run` will encounter similar with respect to dev_txs.
Previously, when using "development embark" (i.e. `embark` command in the
monorepo) the template generator would always use `yarn install` to install a
template's dependencies. However, if a template relies on `package-lock.json`,
as is the case for `embark-create-react-dapp-template`, that behvaior can cause
serious problems. So, have the choice of install command depend not only on
whether we're using "development embark" but also whether the template has a
`package-lock.json` file.
NOTE: this change can probably result in problems given that `yarn install` and
`npm install` behave differently re: symlinks in `node_modules`. However, such
problems would never show up with production installs of the `embark`
packaage. Moreover, after dropping `embarkjs-connector-web3` we don't presently
have a situation where a monorepo package would be `yarn link`ed into an
instantiated template's `node_modules`. So, in effect, the changes introduced
in this PR allow existing templates to work correctly whether using production
or monorepo embark. The impending embark v5 refactor should deprecate `embark
new` in favor of the yet unfinished `embark init`.
When passing the name of a build pipeline that doesn't exist, e.g.
`embark run|build --pipeline foo`, `writeStats` would cause an unhandled
promise rejection because its config argument is falsy. Checking for that and
returning early from `writeStats` allows the `"no webpack config has the name
'foo'"` error to be reported correctly.
The ignore paths for the default webpack config and babel-loader-overrides
helper script weren't properly adjusted after the legacy pipeline was split-out
into its own package in the monorepo.
Upgrade all dependencies on web3/web3-* v1.0.0-beta.37 to v1.2.1.
Make various adjustments related to the previous convention of
`"web3": "1.0.0-beta"` in `embark.json` signifying that embark's own web3
dependency should be used in dapp builds.
Fix bugs in library manager, including a switch from using the
live-plugin-manager package to using npm in a child process to install
`"versions"` dependencies specified in `embark.json` when a specified version
doesn't match up with embark's own version for that package.
Avoid race conditions when installing `"versions"` by completing all installs
prior to starting other services. If an install fails, then after all the
installs have completed or failed the embark command will exit with error.
Change various comments and update docs to reflect the new default of web3
v1.2.1.
In https://github.com/embark-framework/embark/commit/87d92b6091 we've introduced a feature in our test runner
to report exact gas costs used when calling Smart Contract methods that
cause computation.
Embark keeps a list of deployed contracts in memory and for all transactions
happening during tests, it'll match them to the contracts that performed them
to produce the report logs.
Unfortunately, we've been [resetting that memory](https://github.com/embark-framework/embark/commit/87d92b6091#diff-92b4f79a0473160fe700440b1ced5204R140) of deployed contracts
after every test, making it practically impossible for Embark to find
matching contracts for any transactions, because contracts aren't necessarily
redeployed per spec, resulting in no additional transaction logs whatsoever.
This commit ensures that the memory is never erased and at the same time
ensures it's not leaking infinitely in case multiple contracts are
deployed multiple times in the same process over several specs.
We've introduced a regression in 536a4029ba where the default
`value` sent to payable Smart Contract methods is `-1`, resulting in errors as it's not
a valid value.
For payable methods inside of the contract interatction section of cockpit, the value input has been updated to pass wei to the API. The input field now accepts value like `100 ether` or 25 szabo`. The value entered is automatically converted to wei and shown to the user in real time.
Additionally, the input is validated for a correct value, with an error shown to the user for incorrectly entered values.
A tooltip has been added to help the user enter correct values.
UI updates can be seen in video here: https://monosnap.com/file/642cHH2HxDeiFLzB2VLqHP9GuqoRfz
This is due to a bug that has been introduced in d10c0b7951 where we end up
sending values as numbers to web3's `toWei()` utility. The `value` is always sent as number
and in fact always defined, so we just need to check for it's type and convert it to a string
according to `toWei()`'s API.
When running tests against non-simulated blockchain nodes, even for simplex
Smart Contracts, deployment transactions would exceed the block gas limit.
E.g. running `embark blockchain` in one process and `embark test --node embark`
in another, inside our demo application, will throw an error when Embark attempts
to deploy its `SimpleStorage`:
```
Compiling contracts
Compilation done
[SimpleStorage]: error deploying =SimpleStorage= due to error: Returned error: exceeds block gas limit
Error deploying contracts. Please fix errors to continue.
Error deploying contracts. Please fix errors to continue.
terminating due to error
Error deploying contracts. Please fix errors to continue.
```
The reason for that is because in https://github.com/embark-framework/embark/pull/1650, we've introduced a static
gas estimation for Smart Contract deployment that is just right below Ganache's
maximum gas limit of `6721975`, since Ganache tends to underestimate gas for
complex Smart Contracts due to its [low base fee](8ad1ab29de/lib/utils/gasEstimation.js (L33-L39)).
The static gas estimation would apply any time we're in a test context, but we
didn't take into account the case where tests are executed against nodes
other than the simulated environment.
As mentioned in the comments in the linked PR:
> If this is not spec'ed at all, I wonder what complications it could cause when
> at some point we maybe switch to not using Ganache anymore for tests, or even
> the user itself (which I think is a reasonable thing to do).
This causes the error described above because we easily reach the block gas limit
with just two Smart Contracts and Embark already deploys a few Smart Contracts for
ENS.
So basically what we want is to use the static gas estimation when we know
the node we're connecting to is Ganache. In all other cases we can rely on the
standardized gas estimation offered by the node.
Adjust the API endpoints to augment transaction objects with a timestamp
property from their corresponding blocks. This removes the necessity to copy
the timestamp property from a block to its transactions in the client.
Introduce a `formatTimestampForDisplay` util function in Cockpit for
consistently transforming timestamps into relative or absolute dates, depending
on whether a date is sometime during the last day.
The property is set/available on EmbarkJS in the artifacts, i.e. in a browser
build; but sometime since v3.2.4 it was no longer availble in the cli dashboard
environment.
`EmbarkJS.Messages.isAvailable()` in some cases return synchronously (when whisper isn't
set up), in other cases asynchronously. This actually breaks our demo application for
the following reason:
We check for Whisper's availability via:
```
EmbarkJS.Messages.Providers.whisper.getWhisperVersion((err, _version) => {
if (err) {
return console.log(err);
}
this.setState({whisperEnabled: true});
});
```
There's a couple of problems here:
- This code will break right away when whisper isn't available, resulting in an error:
```
Cannot read property _requestManager of undefined
```
- The reason this error happens is because there's no `web3` object available inside
our EmbarkJS.Messages code. Even though there **is** a web3 object, EmbarkJS.Messages
doesn't know about this because it only sets it when its `setProvider()` API is called,
which effectively doesn't happen at all when Whisper isn't enabled on the connected
node
- While this could be fixed with a simple check on whether EmbarkJS.Messages' internal
`web3` references is a thing, really what should be used in the demo is the `isAvailable()`
API.
`isAvailable()` should always return a promise (similar to `EmbarkJS.Storage.isAvailable()`.
This commit ensures that `isAvailable()` always returns a promise and changes the demo
template to use `isAvailable()` over `getWhisperVersion()`.
Effectively deprecate the `embarkjs-connector-web3` package but don't introduce
a breaking change by simply not loading the plugin if it's specified in a
DApp's `embark.json`. If the deprecated plugin is specified, display a message
indicating the plugin was ignored and suggesting it be removed from the
project's `embark.json` and `package.json`.
This PR adds a command to get full account details from the contradts config that includes info like private key.
The existing, and similar command, `blockchain:provider:contract:accounts:get` would only return account addresses if they existed, and not the full account info.
This check was already made when sending messages to whisper channel, however, we didn't
perform the same check when subscribing to channels within cockpit.
The webserver's job is to serve files generated by Embark's built-in pipeline,
however, since v4 users can choose they front-end tool to take care of building,
bundling and packing their DApps. Usually these tools come with a built-in
dev server as well.
Therefore, when the pipeline is turned off (which also soon will be the default),
there's not need start a webserver.
In https://github.com/embark-framework/embark/pull/1119 we've introduced a feature where
users can provide an already compiled ABI for Smart Contracts so they can be used
without the need to compiling them again.
This also means that, internally, those Smart Contract object won't have any
bytecode attached to it.
Later on, in 387d33a076, we've introduced a warning
which is rendered when a Smart Contract's bytecode is too large. The check expects
a Smart Contract object to have bytecode associated to it, which will break the code
in cases where a Smart Contract has already an ABI and therefore didn't need compilation.
This commit ensures we only check a Smart Contract's bytecode when bytecode exists for
the Smart Contract in question.
When trying to either sending, or listening to whisper channels within
Embark's consoles (CLI and Cockpit), the console outputs an error that
`EmbarkJS` isn't defined.
E.g. running:
```
> EmbarkJS.Messages.listenTo({ topic: ['somechannel'])
```
Outputs:
```
EmbarkJS is not defined
```
This seemed very odd as outputting `EmbarkJS` and all of its members
worked totally fine.
It turns out that both methods, `listenTo()` and `sendMessage()`, in
`EmbarkJS.Messages` are not necessarily what one thinks they are.
EmbarkJS decorates both methods to create some options that need to be
available in the delegate, two of them being `EmbarkJS.Utils.toAscii`
and `EmbarkJS.Utils.fromAscii` (ac76a40a61/packages/embarkjs-whisper/src/index.js (L43-L62) and ac76a40a61/packages/embarkjs-whisper/src/index.js (L64-L73))
These two global references to `EmbarkJS` are the only ones in `embarkjs-whisper`
and they are not the same reference as the `EmbarkJS` sandbox global
registered in the VM here ac76a40a61/packages/embark-code-runner/src/index.ts (L33).
In other words, the `EmbarkJS is not defined` message actually refers
to the `EmbarkJS` in the wrapping method, not the one registered with
the VM, which is also why inspecting the `EmbarkJS` object through the
VM works fine.
Since the `toAscii()` and `fromAscii()` methods in use are really just
facades around `web3.utils.[fromAscii|toAscii]()`, we can replace the
global EmbarkJS dependency with web3 utils that are already available
anyways.
Upgrade chokidar to a version that's compatible with NodeJS v12.x.
Unfortunately, embark has other transitive dependencies that are not compatible
with v12.x, but upgrading chokidar is still a good step.
When running unit tests inside a project that configures ENS subdomains using Smart Contract directives,
the tests will output an error because of that particular Smart Contract's `deployedAddress` being `undefined`.
This happens only when running tests, not when deploying the Smart Contracts including the custom ENS setup.
It turns out that Embark attempts to compile and deploy the Smart Contracts of the project *twice* - once
before tests are executed, and another time **after** tests are done executing.
Both compilations/deployments are triggered through our custom `config()` function within test context,
which ensures all Smart Contracts are deployed before tests are executed.
This explains a few things:
1. There's no such issue when running `embark run`, in fact the custom ENS subdomains work perfectly fine
2. That's also why the tests are passing fine as well as the first compilation/deployment doesn't have any issues.
The errors only appear *after* the tests have been executed.
Still, this raises a few more questions, mainly
- Why is the Smart Contract's `deployedAddress` property `undefined` when `config()` is executed a second time?
- Why is `config()` executed a second time in the first place?
Let's look into both of these.
Assuming that there's a valid reason that `config()` is called twice, it's remains unclear why that property
of a Smart Contract object is `undefined` in the second run. The reason for that is that Embark determines whether
or not a particular Smart Contract should be deployed. One of the routines ensures that only the Smart Contracts
configured for deployment are actually attempted to be deployed (as opposed to just deploying all Smart Contracts
found in the file system).
It turns out that the second `config()` call is done without any Smart Contract configuration, resulting basically in no deployment
for any Smart Contract of the application. The `address` and `deployedAddress` of a Smart Contract object are however only set
*after* deployment, resulting in them being `undefined`.
**All this makes sense.**
`config()` is simply not designed for being used with an empty `contracts: {}` config. This raises another question:
Why is `config()` called with an empty configuration? This leads us to the second point.
It does seem a bit weird that Embark tries to configure compile *and* deploy a DApp's Smart Contracts again right **after**
the tests have been executed. So why is that?
A quick `git blame` (no blame intended here) shows us that this routine has been introduced in https://github.com/embark-framework/embark/commit/12cbb7bdd.
Notice the second list point of the commit:
> Contracts that had been compiled in the JS tests were being deleted at the end of the JS test run, which caused errors
> with the files not being found. The fix was to reset the contracts config to no longer require the non-test contracts
> to be compiled/deployed.
The above is a little tricky to understand without a little bit of context: Embark runs two types of tests, JavaScript tests
and Solidity tests. It does that as part of a single process, keeping state in memory in-between those two test runs.
With that in mind, the commit mentioned above says the following:
1. Artifacts that Embark generates as part of its compilation process are erased after JS tests are done executing.
This makes a lot of sense as we don't want to leave any side effects undone when tests are finished.
2. The commit ensures that not only the artifacts are removed from disc, but also updates Embark's state in memory
for `contractFiles`. The reason for that is that otherwise, in the second test run for Solidity tests, Embark will
throw errors as it tries to look up the path for the artifacts in memory for all the Smart Contracts that had been
compiled before.
3. Last but not least, there's *another* state that needs a reset and that's the Smart Contract configuration. If Embark
doesn't reset the memory it'll assume in the second run that all of those Smart Contracts left in memory
"have no code associated to it", while in reality, they shouldn't be in memory in the first place.
So it seems that `config()` is called a second time with an empty Smart Contracts configuration just to ensure that memory
is reset and no error messages are shown.
As discussed earlier, this unfortunately also introduced a lot of side effects along the way as Embark tries to reregister
ENS subdomains from Smart Contracts that are marked as undeployed and therefore don't have an address to interpolate.
While there's probably different ways to go about it, the most straight forward fix is to simply not call `config()`
a second time when it's really not needed. If the goal is to just reset the memory, we can take advantage of
Embark's internal `config:contractsConfig:set` event, which is what this commit is doing.
The embark-utils package, since 4.1.0-beta.1, is a transitive DApp dependency;
but it's loaded in the main process (not a child process), so embark-utils' own
deps can't be indirectly supplied from embark itself via NODE_PATH.
When introducing the `embark-api-client` in https://github.com/embark-framework/embark/commit/c1bbdbf34
we didn't properly update Cockpits apiService, resulting in calls to API endpoints
that don't exist.
This commit fixes a bug where calls to Embark's API to subscribe to whisper
channels are in a broken state.
It also updates Cockpit's apiService to no longer pass ignored parameters to embark-api-client.
With the move of Embark's modules into their own packages, the names under
which they are registered in the API service have changed as well.
This caused Cockpit to no longer being able to properly detect whether
ENS is enabled in the current Embark project
This package comes with a `setUpEnv()` function that can be called to
prepare Embark's environment variables for different process contexts.
This allows us to set up Embark's environment within a test runner context
without the requirement of importing `packages/embark/src/lib/core/env.js`,
which happens to set up those necessary environment variables as a side effect.
It's important that a path to `packages/embark`'s root is passed down to `setUpEnv()`
to ensure `EMBARK_PATH` gets the correct value.
E.g. within a package `embark-console`, `setUpEnv()` can be called within its tests
like the following:
```
// packages/embark-console/src/test/console.js
import { joinPath, setUpEnv } from 'embark-utils';
setUpEnv(joinPath(__dirname, '../../../embark'));
```
Here, `__dirname + '../../../embark'` ensures `EMBARK_PATH` points to the root
of `packages/embark`. This might look different in other contexts.
For example calling this function from a test file within `packages/embark`, this would
look like this:
```
// packages/embark/src/test/some_file.js
import { joinPath, setUpEnv } from 'embark-utils';
setUpEnv(joinPath(__dirname, '../../'));
```
As part of 880a3a6946, we've introduced a
regression where the `colors` package isn't imported in the scope anymore where it's
needed. In this case the pipeline package. This resulted in log output messages
such as:
```
undefinedwriting fileundefined
```
Adding the `colors` package as dependency and importing it accordingly
fixes the issue.
Make the adjustment even if the test script is currently disabled. Consistently
use nyc to generate coverage with mocha even if the test script is currently
disabled.
If the `embark` cli is detected to be inside the monorepo, the template
generator yarn-links any template deps that are part of the monorepo into the
dapp. However, `embarkjs-connector-web3` now has a dependency on `embark-core`,
which in turn has a dependency on `embark-i18n`. That causes `npm install` to
fail inside the dapp because npm checks for deps of `embarkjs-connector-web3`
relative to the dapp instead of checking relative to the symlink. `yarn
install` does not suffer from that behavior so use it instead.
Move the debugger module to the `embark-debugger` package.
Handle case where `debug` is entered as a console command, and there is no transaction to be debugged.
add embark-i18n and mocha deps
Add support for `service api on/off` commands.
Deprecate commands `api start/stop` in favor of `service api on/off`.
`service api on` - Enables the API server serving Cockpit. Shows an error if the API server is already starting or started.
`service api off` - Disables the API server serving Cockpit. Shows an error if the API server is already stopping or stopped.
`api start` - This command has been deprecated in favor of `service api on` and will be removed in future versions.
`api stop` - This command has been deprecated in favor of `service api off` and will be removed in future versions.
`api:start` - This event has been deprecated and will be removed in future versions.
`api:stop` - This event has been deprecated and will be removed in future versions.
Remove support for `service whisper on/off` because Whisper cannot be started without first disabling it in the communications config, then restarting Embark.
Add documentation for the `service [process] on/off` command
This command was only added a few commits back so it is not considered a breaking change.
Refactor the `service [process] on/off` commands so that there is only one command. Previously we had a command registered for each process, ie:
```
service blockchain on/off
service ipfs on/off
…
```
Now, we only have one command with many options:
```
service [process] on/off - Starts/stops the process. Options: blockchain, embark, ipfs, api
```
Whisper is deliberately not included in the available options for the aforementioned reasons.
This enables removing unnecessary `core/fs` dependencies which can be
replaced with `fs-extra`.
This commit also fixes a bug introduced in f868d1216d
where methods from `embark.fs` weren't available.
The reason for that is because we have several *Process instances
that are created through child process communication, specifically
process.send() APIs. Using those APIs, we can only send data structures
however, methods attached on any of those will get lost.
This is the case when sending embark.fs through process.send().
We still need fs in those places though, mostly because they are relying
on embarkPath and dappPath().
These places are now importing those functions from `embark-core`. Other
API such as writeFile or mkdirp() can be accessed through fs-extra
or fs modules.
This pull-request upgrades `ethereumjs-wallet`, which has upgraded the underlying dependency on scrypt.js to 0.3.0, making scrypt an optional dependency and offering a pure JS version as a fallback.
The reasoning behind this is that scrypt is problematic to install in some systems, particularly those that don't have node-gyp setup and we have seen some weird issues when installing with elevated privileges (i.e. `sudo npm install -g scrypt`)
This avoids mistakenly placing process event handlers on the parent process
whenever the `embark-core` package is loaded. Also, don't listen for an
`'exit'` event on `process` and then call `process.exit(0)` since the event "is
emitted after the child process ends" ([docs][docs]), i.e. it's unnecessary to
do so and in any case it's not correct to always exit with code `0`.
[docs]: https://nodejs.org/docs/latest-v10.x/api/child_process.html#child_process_event_exit
Add support for ability to start and stop Swarm via command `service swarm on/off`.
Fix issue with swarm not starting due to missing web3 object.
`service swarm on` - starts a swarm node if not already started. Shows an error if the node is already starting or started.
`service swarm off` - kills the running swarm node as long as Embark has started the swarm process. If the swarm process was started externally, an error is shown.
In addition to introducing improvements per #1492 and #1494, adjust the
transactions request action to allow for a `blockLimit` argument, since that
API parameter is supported by embark.
Revise `changePage` to invoke `fetchTransactions` correctly, i.e. with
arguments pertaining to a starting block number and a block limit.
These changes together fix most of the pagination problems related to exploring
transactions, i.e. badly mis-ordered results are no longer displayed.
However, a *wart* still remains related to estimation of the total number of
transactions and pages. Sometimes the calculated number of pages for the
transactions explorer doesn't match up to the actual number of transactions on
the blockchain (owing to estimation). The pagination controls and display of
transactions will temporarily behave a little strangely if one jumps ahead in
the pages, e.g. a jump from cockpit explorer overview's transactions page 1 to
page 5 for embark's demo, if an additional transaction has been added and the
explorer overview is freshly loaded. This behavior is related to the fact that
actions such as `fetchBlocksFull` and `fetchTransactions` are async without any
means to determine when all actions have completed and React re-/rendering has
settled down.
There are probably some architectural changes that could improve the situation,
but they're outside the scope of this PR and in no way easy to solve by means
of React lifecycle methods. In fact, attempts to make an improvement with
`componentDidUpdate` (and watching what happens in the debugger) revealed the
nature of the problem, as described above.
Add support for ability to start and stop IPFS via command `service ipfs on/off`.
Add support for `ProcessState.Errored` process state in the `ProcessManager`. This allows for processes being launched and stopped to trigger an error and the resulting process will be in an errored state. Processes in errored states can still attempt to be started and stopped.
`service ipfs on` - starts an IPFS node if not already started. Shows an error if the node is already starting or started.
`service ipfs off` - kills the running IPFS node as long as Embark has started the IPFS process. If the IPFS process was started externally, an error is shown.
return early
We could use similar comments for imports related to other `@types` packages,
but the need to do it for `@types/embark` (located in
`packages/embark-typings`) seems more pressing since `import ... from "embark"`
statements in the monorepo can be so easily misunderstood.
Note that the comments, and indeed the whole lines, are automatically erased
during babel transpilation of TypeScript since TS types aren't relevant after
the `.js` files are built.
If a package uses only `.js` then supply `--extensions ".js"`. If a package
uses only `.ts` then supply `--extensions ".ts"`. If a package uses both, then
supply `--extensions ".js,.ts"`.
The reason for this is that adding/removing TS/JS support ought to occasion
revising a package's `package.json` file and adjusting other scripts as well,
e.g. for linting. With these changes, it won't work to simply start adding
`.ts` files in a package's `src/` directory, which should prompt the developer
to review `package.json` and make the appropriate changes, and/or other
developers may realize changes need to be made during code review.
Implement scripts to collect coverage reports (JSON format) from all packages
in the monorepo that generate such reports. Reports are copied to
`<root>/.nyc_output/coverage-[pkg-dir-name].json`.
Implement scripts to generate a combined html report in `<root>/coverage`.
Adjust root `reset` and `clean` scripts to delete `<root>/.nyc_output` and
`<root>/coverage`.
Implement a script in `<root>/package.json` to generate a `text-lcov` report
and upload it to coveralls from CI builds. Remove coveralls from
`packages/embark`.
Supply `packages/embark` with an nyc configuration in its `package.json` and
have its `"test":` script generate both `json` and `html` reports.
Use nyc with `embarkjs`'s test suite: supply an nyc configuration in its
`package.json` and have its `"test":` script generate both `json` and `html`
reports.
Adjust `embarkjs`'s tests for more accurate coverage reporting.
Add support for `service webserver on/off` commands.
Deprecate commands `webserver start/stop` in favor of `service webserver on/off`.
Handles passing through of arguments to the function executed after process launch.
`service webserver on` - Enables the webserver serving the DApp. Shows an error if the webserver is already starting or started.
`service webserver off` - Disables the webserver serving the DApp. Shows an error if the webserver is already stopping or stopped.
`webserver start` - This command has been deprecated in favor of `service webserver on` and will be removed in future versions.
`webserver stop` - This command has been deprecated in favor of `service webserver off` and will be removed in future versions.
Several `embarkjs-*` packages specify a `"test":` script in their respective
`package.json` files but lack any tests, causing `yarn test` in the root of the
monorepo to fail. For now, disable those scripts.
Add support for `service blockchain on/off` in the console.
Add service on/off command for each process started by, ie `service blockchain on/off` and `service whisper on/off`.
`service blockchain off` - Kills the blockchain process, stops the web3 provider, and shuts down the proxy (if used). In the case of `embark blockchain`, the entire process is exited.
`service blockchain on` - Starts the blockchain process *as a child process of the main embark process* then starts the web3 provider. This happens regardless of whether or not it was initially started with `embark blockchain` (see known issues).
## Known issues
1. If the blockchain process was started with `embark blockchain`, and then the blockchain process is killed with the `service blockchain off` command, when the blockchain process is restarted with `service blockchain on`, it will be restarted as a child process of the main embark process. It may be possible to allow for the blockchain process to be restarted in the same process it was originally started in, however this will take more development effort and can be handled in a different PR.
2. Parity has not been tested as it is currently not working in the master branch.
3. This PR adds a generic registration of commands for each process, ie `service whisper on/off`, however the only supported command is the `service blockchain on/off` command. Further support for other commands can be handled in separate PRs.
Errors emitted as part of the `deployAll()` routine got swallowed by
Embark, leaving users in the unknown when the deployment process
"froze".
This commit ensures errors emitted are now logged, making it obvious
when something went wrong.
This commit introduces a feature where users can specify which files should be removed
as part of Embark's `reset` command.
This is done by specifying the `options.reset` section in a project's `embark.json`.
The possible options are `defaults: bool` and `files: Array<String>`:
```
// embark.json
{
...
"options": {
"reset": {
"defaults": true,
"files": ["some.file", "some/other.file"]
}
}
}
```
`defaults` tells Embark whether or not it should remove the default files that are
defined by the `reset` command. Setting it to `false` will prevent Embark from
removing any of these (mostly files located inside `.embark`).
This gives users fine control as they now can re-add subsets or those file paths
in the `files` property.
If `options.reset` doesn't exist Embark will do the default behaviour, which is
is simply resetting/removing the files it has always removed.
It now also honors `generationDir` and `buildDir` as part of the defaults.
`webSocketProcess` function in `embark-api-client` expects only a process name,
but cockpit was calling it with name-strings prepended with `/process-logs/`
resulting in bad URLs. Revise cockpit's `services/api` module to call
`webSocketProcess` with process names only.
Embark API server's development proxy from port 55555 to 3000 was attempting to
inappropriately forward an `/embark-api/` endpoint for the blockchain process
logs to Create React App's development server. Why it was only happening for
the one endpoint is not known but probably has to do with timing around
registration of the API server's express routes.
The problem can be fixed with a one-line `filter:` function in the options for
`express-http-proxy`. However, it was realized that to fix an unrelated
problem, whereby the proxy doesn't forward websockets to CRA such that hot
reload doesn't work when accessing `embark-ui` in development on port 55555, a
switch to `http-proxy-middleware` would be required. That was quickly
attempted (easy switch) but there are outstanding [difficulties][bug] with
`webpack-dev-server` and `node-http-proxy` that cause CRA to crash.
Switch strategies and refactor the API module to serve a page on port 55555 (in
development only) that alerts the developer `embark-ui` should be accessed on
port 3000. The page redirects (client-side) after 10 seconds, with URL query
params and/or hash preserved. A future version could instead do client-side
polling of port 3000 with `fetch` and then redirect only once it's
available. The reason for not redirecting immediately is that the intermediate
page makes it more obvious what needs to be done, e.g. CRA dev server may need
to be started with `yarn start`.
[bug]: https://github.com/webpack/webpack-dev-server/issues/1642
This commit enables new `beforeDeploy` deployment hooks. With this change
it's possible to add `beforeDeploy` to either `contracts: {}` within the contracts
configuration, or an individual contract.
For example:
```
contracts: {
SimpleStorage: {
beforeDeploy: async (context) => {
}
}
}
```
Runs the hook before `SimpleStorage` will be deployed. Whereas
```
contracts: {
...
beforeDeploy: async () => {
}
}
will be executed before *all* Smart Contracts will be deployed.
This will allow users to generated deploy hook specific output using the supplied `logger` within deployment hooks.
The logger will generate an output a la:
```
ContractName > deploymentHook > Output
```
and
```
afterDeploy > Output
```
respectively.
E.g. an `onDeploy` hook config like this:
```
contracts: {
SimpleStorage: {
fromIndex: 0,
args: [100],
onDeploy: (context) => {
context.logger.log('Hello from on deploy');
}
}
}
```
Will output:
```
SimpleStorage > onDeploy > Hello from on deploy
```
Support embarkjs-whisper with external pipeline.
`embarkjs-whisper` is required by code that is through the VM, and therefore the `embark` package needs to be able to resolve `embarkjs-whisper`.
Create a dev tx (a 0-value tx that is sent from the —dev account to itself) when a request goes through the proxy, but does not get a response after 5 seconds.
Log requests to disk (when log level is trace - enabled with the embark option `—loglevel trace`) that have not received a response and for which a dev tx has been sent.
Add logging to a `proxyLogs.json` log file as well, so that this information can be gleaned later for debugging purposes.
This particular PR Is meant to workaround an issue with running geth with the `—dev` option, as some transactions appear to get stuck, which then builds up further txs in a queue. Only when another tx is sent is the queue then purged as expected.
The remaining issue is that even though a dev tx is sent to relieve the queued txs, the originally offending tx still never receives a response from the node. This was the motivation behind creating a proxy log, so that a dev can inspect the txs that are essentially dropped.
**NOTE:** the base branch of this branch is `refactor/devfunds`. Please merge that branch first.
Change name “DevFunds” to “DevTxs”.
Remove unused functions in dev_funds (create accounts, unlock accounts, fund accounts).
Add console command `sendtx` to send a one-off dev transaction.
Modify the dev tx to send a 0-value tx to itself (ie the `web3.eth.defaultAccount` which is the `—dev` account).
Deprecate the command `regularTxs on/off` in favour of `devtxs on/off` (notice the casing).
Strip regulartxs from cockpit and modify the browser warning to instruct users to run a console command.
This commit has been originally cherry-picked from d0d89fc5ae and
slightly modified to update all packages, as meanwhile, new packages have been added to `master`.
The reason this commit is cherry-picked from `4.0.x` branch is because
it wasn't created from `master`.
Purpose is mainly to update `CHANGELOG` and get the package versions in sync again.
Display five contracts per page in the dashboard. Display ten contracts per
page in the contracts explorer and deployment page.
Sort contracts by name. In the future we can implement an option to sort by
block number and index within a block by calculating and including that
information as part of the server-side api response (based on a contract's
txhash).
Remove unnecessary contract filtering in the components since the containers
take care of it.
Make use of `listenToContracts` / `stopContracts` in DeploymentContainer.
feature(@embark/embarkjs-whisper: make embarkjs whisper plugin a module on its own
feature(@embark/embarkjs-whisper: make embarkjs whisper plugin a module on its own
Iuri Matias
emizzle
Michael Bradley, Jr
Jonathan Rainville
Pascal Precht
dependabot-preview[bot]
André Medeiros
snyk-bot
Ricardo Guilherme Schmidt