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
```
Michael Bradley, Jr
Jonathan Rainville
emizzle
Pascal Precht
Andre Medeiros
Iuri Matias