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.
Make changes by running these commands in the root of the monorepo:
**bugs**
```shell
npx lerna exec --concurrency 1 --stream -- \
'DIRPATH=$(realpath $PWD --relative-to=$LERNA_ROOT_PATH); \
npx json -I -f package.json -e "this.bugs=\
\"https://github.com/embark-framework/embark/issues\""'
```
**homepage**
```shell
npx lerna exec --concurrency 1 --stream -- \
'DIRPATH=$(realpath $PWD --relative-to=$LERNA_ROOT_PATH); \
npx json -I -f package.json -e "this.homepage=\
\"https://github.com/embark-framework/embark/tree/master/${DIRPATH}#readme\""'
```
Don't commit changes to private packages, with the exceptions of embark-typings
and embark-reset because those may switch from private to public, and also
because the latter will be included in `node_modules` of embark even if it is
private since embark-reset is presently a bundled dependency of embark.
Don't include the homepage and bugs fields in dapps generated from the template
packages, except for the demo. Set those dapps' description field to an empty
string.
Ensure every package (inc. private packages) has a description.
Ensure every package (inc. private packages) has a README that begins with:
```markdown
`[pkgJson.name]`
================
> [pkgJson.description]
Visit [embark.status.im](https://embark.status.im/) to get started with
[Embark](https://github.com/embark-framework/embark).
```
Don't include the README in dapps generated from the template packages, except
for the demo.
See: https://github.com/npm/rfcs/blob/latest/implemented/0010-monorepo-subdirectory-declaration.md
Make changes by running this command in the root of the monorepo:
```shell
npx lerna exec --concurrency 1 --stream -- \
'DIRPATH=$(realpath $PWD --relative-to=$LERNA_ROOT_PATH); \
npx json -I -f package.json -e \
"this.repository=\
{\"directory\": \"$DIRPATH\", \
\"type\": \"git\", \
\"url\": \"https://github.com/embark-framework/embark.git\"}"'
```
Don't commit changes to private packages, with the exceptions of embark-typings
and embark-reset because those may switch from private to public, and also
because the latter will be included in `node_modules` of embark even if it is
private since embark-reset is presently a bundled dependency of embark.
Don't include the repository field in dapps generated from the template
packages, except for the demo.
Previously, templates were in a subdirectory of `packages/embark`. Reorganize
them so that they are member packages of the monorepo. This allows them to
cleanly depend on other members of the monorepo,
e.g. `embarkjs-connector-web3`.
It is desirable for the templates, in the context of the monorepo, to specify
embark as a dependency, to take advantage of `npx embark test` (and it's a
"forward looking" setup re: how we plan to evolve embark). However, if embark
were to specify the template packages as dependencies a circular relationship
would be introduced, which is [unsupported by Lerna][circular]. Therefore,
revise the template generator so that all templates are resolved / fetched at
runtime, i.e. `boilerplate`, `demo`, and `simple` are no longer
"built-ins" *per se*. This change won't be apparent to embark's users, but it
does mean that the template generator won't work (in a production install of
embark) if it can't connect to the npm registry, i.e. when the user runs
`embark demo` or `embark new [--simple]`. When embark is inside the monorepo,
templates are resolved and copied from the yarn workspace rather than being
fetched from the registry, which is convenient for development. Also, any
template dependencies that are members of the monorepo are linked into the
copied template's `node_modules` rather than being installed from the registry,
again for convenience. During template generation, remove scripts and
dependencies that pertain only to membership in the monorepo; for now, that
involves removing embark as a dependency since we're not quite ready for that
arrangement to be the default, i.e. outside of the monorepo.
Refactor the root scripts so that more of them can consistently be used with
Lerna's filter options, e.g. `--scope` and `--ignore`. "Combo" scripts that
don't support filtering generally have a `:full` postfix.
Flip `clean` and `reset` scripts at the root and in the member packages for
consistency re: Lerna's notion of `clean` and embark's notion of `reset`. Have
each package run its `reset` script when its `clean` script is invoked (and
that's all for now), relying on `lerna clean` to delete packages'
`node_modules` in view of how Lerna's topological sorting works.
Lift the implementation of `embark reset` into a private package in
`packages/embark-reset` and make it a bundled dependency of embark. Packages in
`dapps/*` depend on `embark-reset` directly and make use of it with `npx
embark-reset` (but only in monorepo context). This removes a "wart" where
reboots could show errors when embark's sources aren't already built in
`packages/embark/dist`. Users will not notice any difference since `embark
reset` works as before, transparently making use of the `embark-reset`
package. The only downside to having it be a bundled dependency of embark is
that bundled deps have all of their `node_modules` included in the tarball
built with `npm pack` (that's why having the templates as bundled dependencies
of embark isn't a viable approach). However, `embark-reset` only has one
dependency, `rimraf`, which is a tiny module, so the cost seems acceptable.
As part of the reorganization, move `test_dapps` into `dapps/tests` and
`packages/embark/templates` into `dapps/templates`. Keep the directory names
short but revise the package names to facilitate simple filtering with
`embark-dapp-*`. Consolidate `.yarnrc` and `.gitignore` and clean up some
redundant ignore listings.
Scripts run with `--scope embark-dapp-*` use `--concurrency=1` to avoid
conflicts that could arise over network ports. The `ci:full` and `qa:full`
scripts use `--concurrency=1` in all scopes, for two reasons: resource
limitations on Travis and AppVeyor result in slower runs with concurrency >1,
and if something fails in those contexts it's easier to see what went wrong
when Lerna's output isn't interleaved from a bunch of scripts in `packages/*`.
Bump the Lerna version.
[circular]: https://github.com/lerna/lerna/issues/1198#issuecomment-442278902
This PR fixes a number of issues relating to the cockpit console.
#### Console commands display in cockpit console
Fix cockpit console not displaying console usage commands that included “<usage option>”. For example “resolve <name>” would not display the “<name>” part, as it was attempting to write this in as HTML (ansi-to-html conversion).
This was fixed by replacing any instances of “<usage>” with “[usage]”. Please note that future usage strings should not contain text wrapped in “<>”.
#### Autosuggestions for “web.eth.” not appearing
Fix “web3.eth.” not suggesting members of `web3.eth`. This was due to a `Object.keys(web3.eth)` throwing `'getOwnPropertyDescriptor' on proxy: trap returned descriptor for property 'defaultAccount' that is incompatible with the existing property in the proxy target` in the console. Changing `Object.keys` to `Object.getOwnPropertyDescriptor` solved the problem.
#### Fix autosuggestion of known console commands (ie from plugins)
Fix known console commands (ie from plugins) not being autosuggested. For example, typing “web”, should autosuggest `webserver start/stop`, `log webserver on`, and `log webserver off`.
This PR adds in support for registered console commands (from plugins).
For every provider registered and set with EmbarkJS, auto generate events to inform other modules of the state of the provider.
Any provider that belongs to EmbarkJS (currently Blockchain, Names, Messages, and Storage) will have both a `runcode:<provider name>:providerRegistered` and a `runcode:<provider name>:providerSet` event created automatically when the `CodeRunner` is instantiated.
Once the `registerProvider` code is run through the VM, ie `EmbarkJS.Blockchain.registerProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerRegistered`.
Likewise, once the `setProvider` code is run through the VM, ie `EmbarkJS.Blockchain.setProvider(…)`, the corresponding event will be fired, ie `runcode:blockchain:providerSet`.
Additional updates/fixes with this PR:
* Move `CodeRunner` to TypeScript
* Fix console errors with ENS and Storage due to a recent PR that waits for `code-generator:ready`. The solution here was to ensure that `code-generator:ready` is requested, so that premature events can be handled.
refactor(@embark) add fs to plugin api; change (most) modules to use it instead of coupling them with require
refactor(@embark) add fs to plugin api; change (most) modules to use it instead of coupling them with require
refactor(@embark) add fs to plugin api; change (most) modules to use it instead of coupling them with require
refactor(@embark) add fs to plugin api; change (most) modules to use it instead of coupling them with require
refactor(@embark) add fs to plugin api; change (most) modules to use it instead of coupling them with require
refactor(@embark) add fs to plugin api; change (most) modules to use it instead of coupling them with require
fix typings
WIP: refactor
WIP: just needed an annotation 🎉 thanks @emizzle!
WIP: don't pack a tarball since it's a private package
WIP: no need to list as a devDep
emizzle
Michael Bradley, Jr
Jonathan Rainville
Iuri Matias