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
During work on PRs #1492 and #1494 it became evident that it's not desirable to
show pagination controls unless the number of pages is greater than one.
Display a truncated account balance if the balance is greater than 20
characters in length. This keeps the "Balance", "Tx Count", and "Index" fields
well-aligned in lists of accounts.
In the account details page continue to show the full balance.
Display two accounts per page in the explorer overview. Display ten accounts
per page in the accounts explorer page.
Sort accounts by their api-supplied index numbers with the lowest index coming
first.
Change the `initBlockHeader` saga so that it triggers a re-fetch of accounts
and therefore the "Tx Count" numbers of displayed accounts will reflect
increased counts.
During deploy with a failing transaction, embark was crashing due to the variable `line` being passed in as undefined.
Add better error handling to catch this error and prevent embark from crashing.
Make tabs draggable so they can be arranged how the user would like.
The dragging functionality locks the tabs to the parent container.
Support for multiple rows of tabs.
Styling updates for selected tabs.
When connected to metamask, and “Injected Web3” is selected on the Deployment page of Cockpit, check to see if contracts have already been deployed or not.
For contracts that have not been deployed, or set to an address in the config, these should now all be re-deployable.
Supports libraries (that have bytecode with `0x73<address><bytecode>`).
Compare a contract's `originalFilename` property to a contract file's
normalized `originalPath` property instead of `filename`. The `filename`
property seems to have been removed.
Contract app hangs when attempting to test the solc contract in the test folder.
There were several causes:
1. The test contract needed a referenced contract path updated
2. 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.
3. Contract filtering was attempting to filter on a property `filename` that must have been changed to `originalFilename` at some point and therefore was not filtering properly.
4. The accounts used by the contract deployer were getting overwritten when `SolcTest` was instantiated and thus preventing the `remix_tests` `Assert` library from getting deployed.
Fix hang when the storage provider (IPFS or Swarm) was started externally before running Embark.
If IPFS/Swarm was already running before `embark run` was run, then the relevant `registerProvider` and `setProvider` code was not being run through the console, and thus the module init event was never fired, preventing the DApp from being built.
This PR refactors the way the IPFS/Swarm process is launched so that the `registerProvider` and `setProvider` code snippets are run through the console in the case of:
* IPFS/Swarm running externally from Embark
* IPFS/Swarm started in a child process by Embark
* Storage is disabled in the DApp config
TL;DR
=====
Unregister (disable) the service worker in production builds of Cockpit. The
CRA dev server doesn't enable the service worker, so no changes are needed in
that context, i.e. `yarn start` in the monorepo.
**NOTE**: to effect these changes a user will need to load production Cockpit at
`localhost:55555` and then close all Cockpit tabs (or restart the
browser). This should be done for each browser that has been used to access
production Cockpit. See the *Step-by-Step* section below for more information.
Rationale
=========
There are a couple of factors:
* It's a bit confusing that after stopping `embark run` the production build of
Cockpit is still accessible at `localhost:55555`. That's owing to CRA's
[offline-first behavior][PWA] per the service worker it creates, which
Cockpit [currently registers][current] (enables).
* It can be really confusing, if you don't know or forget about the service
worker's behavior, that after a production rebuild of Cockpit the old build
is still used in the browser, even after a page refresh. As [explained][ofb]
in CRA's docs: *"users will end up seeing older content until they
close (reloading is not enough) their existing, open tabs."* A similar effect
is seen when switching between DApps, e.g. teller and embark_demo.
The CRA docs point to [some code][code] that could be adapted to an alert in
the UI prompting the user to close all tabs and reopen the app. That approach
definitely makes sense for DApps built with CRA that have opted-in to the
service worker. In fact, the service worker behavior would be critical in DApps
that make use of connected-/react-router because cold loads of routes that
don't actually correspond to static files couldn't otherwise work, i.e. if the
DApp is being served from ipfs/swarm.
But for Cockpit itself, when served from localhost with an express backend that
we control, little seems to be gained from offline-first behavior vs. a more
familiar behavior, i.e. when `embark run` isn't running then Cockpit isn't
accessible.
Step-by-Step
============
Flushing a site's service worker from cache can be tricky. The following steps
outline an approach to making sure the Cockpit in use is the one with service
worker disabled.
1. The first screenshot below shows the JavaScript console from a fresh load of
Cockpit with the service worker enabled, i.e. from a build on `master` at time
of writing and `embark run` running for the `embark_demo`. Note the messages
re: *"workbox"* and *"precaching"*.
![][step-1]
2. The next screenshot shows what happens when `embark run` is stopped and the
browser is refreshed. Service worker makes the page available offline, though
there are errors related to embark's API not being accessible.
![][step-2]
3. (a) Cockpit gets rebuilt on this PR's `refactor/cockpit-service-worker`
branch and `EMBARK_UI_STATIC=t embark run` is started; see [previous
commit][prevcom] re: `EMBARK_UI_STATIC`. (b) The browser is refreshed. Note the
message at the bottom re: *"New content is available"*.
![][step-3]
4. The Chrome browser is closed completely (command-Q), reopened and
`localhost:55555` is loaded again. Note there are *still* messages re:
*"workbox"* and *"precaching"*.
![][step-4]
5. The page is refreshed again and now the messages are completely gone.
![][step-5]
6. `embark run` is stopped and the page is reloaded, but there's a connection
error because no process is listening on `localhost:55555` — proof that
the service worker is no longer in play!
![][step-6]
Steps 3(b) to 6 will need to be repeated for each browser (Firefox, Safari,
etc.) that visited `localhost:55555` when the service worker was enabled. And
they'll need to be repeated again if the browser is later used with a build of
Cockpit predating this PR.
[PWA]: https://facebook.github.io/create-react-app/docs/making-a-progressive-web-app
[current]: 4d4704ac6f/packages/embark-ui/src/index.js (L39)
[ofb]: https://facebook.github.io/create-react-app/docs/making-a-progressive-web-app#offline-first-considerations
[code]: https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/src/serviceWorker.js#L66-L93
[step-1]: https://user-images.githubusercontent.com/194260/54885199-adfa0900-4e47-11e9-830b-1b92816b2354.jpg
[step-2]: https://user-images.githubusercontent.com/194260/54885202-b3575380-4e47-11e9-9c1e-24817472d9c4.jpg
[step-3]: https://user-images.githubusercontent.com/194260/54885209-bb16f800-4e47-11e9-8e23-8fbc3b4f48fa.jpg
[prevcom]: https://github.com/embark-framework/embark/commit/322033cc
[step-4]: https://user-images.githubusercontent.com/194260/54885212-bfdbac00-4e47-11e9-9c8c-db90228d953a.jpg
[step-5]: https://user-images.githubusercontent.com/194260/54885214-c538f680-4e47-11e9-9963-58fd041675f0.jpg
[step-6]: https://user-images.githubusercontent.com/194260/54885217-ccf89b00-4e47-11e9-967a-7f8a523d4a92.jpg
Implement a `/*` server-side catch-all route for Cockpit that loads Cockpit's
`index.html`.
This change is necessary with intent to disable offline-first behavior in
production builds of Cockpit. Cockpit's service worker effectively translates
server-side route unavailability into client-side behaviors of
connected-react-router. When the service worker is unregistered the same will
be accomplished via the server-side catch-all route.
Implement fallback pages for when embark is in the monorepo but Cockpit's
Create React App development server isn't yet started or isn't yet responsive.
Implement a fallback page for when the static build of Cockpit is missing. When
embark is in the monorepo, give instructions for building Cockpit. Otherwise,
report that the distribution is broken.
Deprecate the environment variable `EMBARK_DEVELOPMENT` in favor of
`EMBARK_UI_STATIC`. Unless the latter is truthy at runtime, when embark is in
the monorepo the CRA dev server of Cockpit will be accessible at
`localhost:55555` via proxied requests to `localhost:3000`. The deprecation is
not a breaking change as `EMBARK_DEVELOPMENT` / `EMBARK_UI_STATIC` are not
relevant to normal users, but only to developers working on embark itself.
Bump `express-http-proxy` to the latest version.
Andre Medeiros
emizzle
Pascal Precht
Michael Bradley, Jr
Jonathan Rainville
Iuri Matias
