Commit Graph

6296 Commits

Author SHA1 Message Date
Jonathan Rainville 13312128b3 fix(@embark/mocha-tests): set accounts correctly on each contracts 2019-12-18 11:22:18 -05:00
Iuri Matias 5893bc38b9 chore(release): 5.0.0-alpha.6 2019-12-17 15:41:00 -05:00
emizzle aea2b6f97f fix(@embark/ens): Show ENS controls for Test DApp
For the test DApp, when ENS is enabled, ENS controls were not showing in Cockpit (under Utils), nor were they available to test in the DApp interface as they did not exist.

Fix ENS controls not showing in Cockpit when enabled.

Add ENS tab to Test DApp for ENS UI.
2019-12-17 13:48:06 -05:00
emizzle 7dfa2b939c fix(@embark/dapps): Contracts app test failure
During `embark test`, the contracts dapp was throwing an error:
```
connection not open on send()
Error: Invalid JSON RPC response: ""
    at Object.InvalidResponse (/Users/michael/repos/embark/node_modules/web3-core-helpers/src/errors.js:42:16)
    at XMLHttpRequest.request.onreadystatechange (/Users/michael/repos/embark/node_modules/web3-providers-http/src/index.js:92:32)
    at XMLHttpRequestEventTarget.dispatchEvent (/Users/michael/repos/embark/node_modules/xhr2-cookies/xml-http-request-event-target.ts:44:13)
    at XMLHttpRequest._setReadyState (/Users/michael/repos/embark/node_modules/xhr2-cookies/xml-http-request.ts:219:8)
    at XMLHttpRequest._onHttpRequestError (/Users/michael/repos/embark/node_modules/xhr2-cookies/xml-http-request.ts:379:8)
    at ClientRequest.<anonymous> (/Users/michael/repos/embark/node_modules/xhr2-cookies/xml-http-request.ts:266:37)
    at ClientRequest.emit (events.js:198:13)
    at Socket.socketErrorListener (_http_client.js:392:9)
    at Socket.emit (events.js:198:13)
    at emitErrorNT (internal/streams/destroy.js:91:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
    at process._tickCallback (internal/process/next_tick.js:63:19)
(node:75120) UnhandledPromiseRejectionWarning: Error: Provider not set or invalid
...
```

This was due to the fact that during testing, the Ganache VM **provider** is used as the blockchain node, instead of spinning up an instance of Ganache. Due to this, there is no HTTP nor WebSockets RPC endpoint opened on the VM node, and the contracts dapp was not able to connect to the node during tests.

Add `$EMBARK` to the contract config’s `dappConnection` list, so that the contract test dapp can successfully connect to Embark’s proxy, which ultimately communicates with the Ganache VM.

As a side note, without `$EMBARK` in the `dappConnection` list, the tests could run successfully when using `embark test —node=embark`. This succeeds because the geth node exposes the RPC WebSockets endpoint that the contracts app connects to on `ws://localhost:8546`.
2019-12-17 10:44:01 -05:00
Pascal Precht aa5121ae0d fix(@cockpit/contracts): ensure contract state is emitted in realtime
This fixes a bug that redeployment of contracts has not been properly
reflected in the cockpit contract list.

The reason for that was that it's listening for a websocket API that
only updates when the `contractsState` event has been emitted.

The commit ensures `contractsState` is emitted during dedicated deployment
events.
2019-12-17 10:43:32 -05:00
Pascal Precht 920b07853a fix(@embark/engine): ensure deployment hook logs don't produce unexpected output
Since ee56f37713, any deployment hook that
was using simple `console.log()` statements to output information, would result in
unexpected `[[object object], [object object]]`.

Unfortunately, the reason for that was that we switched from non-arrow functions to
arrow functions [here](ee56f37713 (diff-a7c4cef8bfebeb39fcd092aca5570fecL324-L340)). Usually switching from non-arrow functions to arrow functions solves
a lot of lexical scope issues where the current reference of `this` isn't pointing at the
right thing.

We're tempering with the global `console.log` inside Embark, which then, combined with
**proper** lexical scope, causes the output described above.

Generally there are a few ways to go about this:

1. Ensure that our custom log functions doesn't turn every log statement into an array output
2. Tell users not to use `console.log` inside deployment hooks and instead rely on `deps.logger`
3. Revert the changes made in the mentioned commit and use non-arrow functions inside `interceptLogs`

Option 2) is not really a solution as we can't simply tell our users that they can't use one of
the most used functions in JavaScript. Option 1) requires finding out why we're formatting logs
by default in an array shapre in the first place. On top of that, we might be relying on this
inside Embark, so it could break certain output.

Option 3) seems to be the most pragmatic solution for now as it doesn't introduce any of the
downsides mentioned above at the cost of using non-arrow functions.
2019-12-17 10:42:14 -05:00
dependabot-preview[bot] 80f189f103 build(deps): bump hexo from 4.0.0 to 4.1.1 in /site
Bumps [hexo](https://github.com/hexojs/hexo) from 4.0.0 to 4.1.1.
- [Release notes](https://github.com/hexojs/hexo/releases)
- [Commits](https://github.com/hexojs/hexo/compare/4.0.0...4.1.1)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-12-17 00:31:40 -06:00
Iuri Matias 78a06c9d76 chore(release): 5.0.0-alpha.5 2019-12-16 13:49:41 -05:00
Bouzaine Chamsddine 5b10a93edb docs: update improve the guide link to the new repo 2019-12-16 11:06:17 +01:00
Bouzaine Chamsddine 209baec7da docs: update the improve the guide link to the new repo 2019-12-16 11:06:17 +01:00
Iuri Matias fc4188d247 bugfix(@embark/parity): add missing new to BlockchainClient initialization 2019-12-13 17:39:02 -05:00
Iuri Matias bd0da80625 bugfix(@embark/geth): add missing new to BlockchainClient initialization 2019-12-13 17:39:02 -05:00
Jonathan Rainville 926b2bb046 fix(@embark/whisper): fix whisper status check 2019-12-13 16:34:01 -05:00
Michael Bradley, Jr ee56f37713 build: implement collective typecheck
This PR replaces #2057.

Implement a collective typecheck action that can be invoked in the root of the
monorepo with `yarn typecheck` or in watch-mode with `yarn watch:typecheck`.
Include the watch-mode typecheck action as part of `yarn start` (a.k.a
`yarn watch`).

To activate collective typecheck for a package in the monorepo, its
`package.json` file should specify:

```
{
  "embark-collective": {
    "typecheck": true
  }
}
```
*-or-*
```
{
  "embark-collective": {
    "typecheck": {...}
  }
}
```

Where `{...}` above is a `tsconfig.json` fragment that will be merged into the
config generated for the package according the same rules that `tsc` applies
when merging [configs][config].

When collective typecheck begins, it generates a `tsconfig.json` for the root
of the monorepo and for each package that is activated for the action. If the
generated JSON is different than what's on disk for the respective root/package
config, or if the config is not present on disk, then it will be
written. Changes to generated `tsconfig.json` files should be committed; such
changes will arise when there are structural changes to the monorepo, e.g. a
package is added, removed, moved and/or the directory containing it is
renamed. Since the configs are only generated at the beginning of collective
typecheck, when structural changes are made in the monorepo `yarn typecheck`
(or `yarn start` or `yarn watch:typecheck`) should be restarted.

Nearly all of the packages in the monorepo (i.e. all those for which it makes
sense) have been activated for collective typecheck. Even those packages that
don't contain `.ts` sources are activated because `tsc` can make better sense
of the code base as a whole owing to the project references included in the
generated `tsconfig.json` files. Also, owing to the fully cross-referenced
`tsconfig.json` files, it's possible for `tsc` to type check the whole code
base without babel (`yarn build` or `yarn watch:build`) having been run
beforehand.

**NOTE** that a *"cold typecheck"* of the whole monorepo is resource intensive:
on this author's 2019 MacBook Pro it takes around three minutes, the fans spin
up, and `tsc` uses nearly 0.5 GB of RAM. However, once a full typecheck has
completed, the next full typecheck will complete in a few seconds or less; and
when running in watch-mode there is likewise a *big* speedup once a full
typecheck has completed, whether that full check happened before it's running
in watch-mode or when watch-mode itself resulted in a full check before
switching automatically to incremental check, as well a corresponding *big*
reduction in resource consumption. A full check will be needed any time
`yarn typecheck` (or `yarn start` or `yarn watch:typecheck`) is run in a fresh
clone plus `yarn install`, or after doing `yarn reboot[:full]` or `yarn reset`.

The combination of options in each generated package-level `tsconfig.json` and
the root `tsconfig.base.json` result in `tsc` writing `.d.ts` files (TypeScript
declaration files) into the `dist/` directory of each package. That
output is intended to live side-by-side with babel's output, and therefore the
`"rootDir"` option in each generated config is set to `"./src"`.

In projects activated for collective typecheck, `.js` may be converted to `.ts`
and/or `.ts` sources may be added without any additional changes needed in
package-level `package.json`.

---

Reorganize types in `packages/core/typings` (a.k.a `@types/embark`) into
`packages/core/core` (`embark-core`), refactor other packages' imports
accordingly, and delete `packages/core/typings` from the monorepo. This results
in some similarly named but incompatible types exported from `embark-core`
(e.g. `Events` and `EmbarkEvents`, the latter being the one from
`packages/core/typings`); future refactoring should consolidate those types. To
avoid circular dependency relationships it's also necessary to split out
`Engine` from `embark-core` into its own package (`embark-engine`) and to
introduce a bit of duplication, e.g. the `Maybe` type that's now defined in
both `embark-i18n` and `embark-core`.

In the process of the types reorg, move many dependencies spec'd in various
`package.json` to the `package.json` of the package/s that actually depend on
them, e.g. many are moved from `packages/embark/package.json` to
`packages/core/engine/package.json`. Related to those moves, fix some Node.js
`require`-logic related to bug-prone dependency resolution.

Fix all type errors that appeared as a result of activating collective
typecheck across the whole monorepo.

Reactivate `tslint` in `packages/core/core` and fix the remaining linter errors.

Tidy up and add a few items in the root `package.json` scripts.

Bump lerna from `3.16.4` to `3.19.0`.

Bumpt typescript from `3.6.3` to `3.7.2`.

Bumpt tslint from `5.16.0` to `5.20.1`.

Make various changes related to packages' `import`/`require`ing packages that
weren't spec'd in their respective `package.json`. More refactoring is needed
in this regard, but changes were made as the problems were observed in the
process of authoring this PR.

[config]: https://www.typescriptlang.org/docs/handbook/tsconfig-json.html
2019-12-13 13:59:47 -05:00
Jonathan Rainville a9c91c9503 chore(@embark/embark): fix embark config test 2019-12-13 10:46:02 -06:00
Jonathan Rainville 60f4d2f27f fix(@embark/embarkjs): use getNetworkId to test connection
This fixes the case when dappAutoEnable is false and tehn in Status
getAccounts returned an error
2019-12-13 10:38:53 -05:00
Jonathan Rainville 7e707616be fix(@embarkrpc-manager): fix infinite loop in eth_accounts modifier
This was caused by the fact that we registered the action to change
the accounts, but that action needs the node accounts, which is
a request to eth_accounts, hence creating a loop
2019-12-13 10:38:53 -05:00
Jonathan Rainville 0503bb24a3 fix: fix node connection test to use the endpoints correctly
This caused issues to connect to Infura for example, because we did
not support HTTPS at all, nor WSS
2019-12-13 10:38:53 -05:00
Pascal Precht 1a7fc663b7 fix(@embark/transaction-logger): handle non-contract transactions
The transaction logger takes care of intercepting any responses coming from the
blockchain proxy, determines what response it's dealing with and then extracts
information from the response to output useful log information to the user, such as
when a contract methods has been called etc.

It turned out that it didn't properly handle cases where value transactions
from account to account (such as done here in [Status Teller](a5ab4d4b26/embarkConfig/data.js (L100-L110))) have been made.

Since Embark couldn't map any of those accounts to actual contracts, while
still having stored corresponding transactions, it logged them as transactions
from "Unknown Smart Contracts".

This commit ensures via heuristics that, if the address a transactions is sent to is
included in any of the nodes accounts, the transaction logger logs a useful message
that a certain value is sent from one to anover account.
2019-12-13 09:45:02 -05:00
Michael Bradley, Jr b630a71f7f test: updated remapImports tests re: `.embark/contracts/node_modules` -> `.embark/node_modules`
Related to #2132
2019-12-12 17:28:23 -06:00
Iuri Matias b25ade64f0 bugfix(@embark/core): remove contracts from path which was causing getting contracts from npm packages not to work 2019-12-12 15:27:40 -05:00
Iuri Matias c00511a0e2 chore(release): 5.0.0-alpha.4 2019-12-12 11:38:22 -05:00
Iuri Matias 5d53847c6f fix(@embark/geth): only register console command if in dev mode; use endpoint; use dev account for regular txs that fix geths stuck tx issue
fix(@embark/geth): only register console command if in dev mode; use endpoint; use dev account for regular txs that fix geths stuck tx issue

fix(@embark/geth): only do regular txs if miningMode is dev

fix(@embark/geth): only register console command if in dev mode; use endpoint

fix(@embark/geth): only register console command if in dev mode; use endpoint

fix(@embark/geth): only register console command if in dev mode; use endpoint

fix(@embark/geth): only register console command if in dev mode; use endpoint
2019-12-12 10:30:43 -05:00
Michael Bradley, Jr 9f2a5949c2 build: specify missing test action in relevant package.json "qa" scripts
It's a relevant `package.json` if the package has a test suite. If `test` isn't
specified then the tests won't run in CI (they have't been running).

Include a fix for one failing test in `packages/plugins/ens` and two failing
test in `packages/stack/deployment`. In all three cases, the mock embark
object's config needed a `blockchainConfig` section with `{ enabled: true }`.
2019-12-11 14:01:12 -06:00
Pascal Precht 9df24309e7 fix(@embark/ens): fix broken test due to async API
As part of 8ed5376533 we made `ENS.getEnsConfig()`
asynchronous, hence it needs a callback. This change was not done in one of the
ENS tests, resulting in the test to fail. The test mocked that particular API,
turning it into noop, which is why the test kept timing out.

This commit fixes the test by not mocking the API and adding the needed configuration
to the environment.
2019-12-11 11:34:27 -05:00
emizzle a208db97b3 chore(@embark/embark): Change default log level
Change default log level for all embark actions (except for tests) to `info`.
2019-12-11 11:31:12 -05:00
Pascal Precht 9839e92584 fix(@cockpit/ens): ensure default account is set when registering subdomains
Prior to this commit, registering ENS subdomains would fail due to `defaultAccount`
being null. This is because the underlying API was still relying on `blockchain:defaultAccount:get`.

However since the bigger refactor, every plugin/module is in charge of creating its own
blockchain connector instance and ensuring it has a default account.

This commit makes use of ENS' module's `webDefaultAccount` async getter to
ensure a valid default account is set when registering an ENS subdomain.
2019-12-11 11:30:58 -05:00
emizzle e72aeba892 chore(@embark/geth): Add back DevTxs
Add back DevTxs.

DevTxs sends a zero-value tx to push through any pending txs that may get stuck with geth while in `—dev` mode.

When the geth client is running, devtxs is started automatically, sending a transaction every 10 seconds.

Converted the legacy code in to typescript.
2019-12-11 11:28:21 -05:00
emizzle acd1d72f2d fix(@embark/tests): Tests exiting early
Tests were exiting early and Mocha was reporting an exit code of 0. This allowed CI to complete as if the tests were successful.

Change `compiler:contracts` event request to `compiler:contracts:compile` and update documentation. Because the `compiler:contracts` event didn’t exist, this test was silently failing.

Update the `TestEvents` mock object to allow passing of parameters to an event that is not a callback.

Add unit tests to test for contracts loaded via node_modules.

1. This PR contains a change where any contracts loaded from node_modules will be imported in to `.embark/contracts/node_modules`. Previously, these contracts were loaded in to `.embark/node_modules` (with the `/contracts`).
2019-12-11 11:27:45 -05:00
emizzle ad26533f4a chore(@embark/core): Set DApp plugins to load last
DApp plugins were already been setup to load last for run and test. This PR sets updates `console`, `build`, `graph`, and `upload` to do the same.
2019-12-11 11:24:40 -05:00
emizzle 8e0f8b44d1 fix(@embark/debugger): Re-enable debugger
Re-enable debugger for cockpit and console.

Add missing request `blockchain:getTransaction` required to start a debugging session.

Fix error in console when stopping a debug session.
2019-12-11 11:12:52 -05:00
emizzle bd4b110a78 feat(@embark/whisper): Add Whisper client config
Add option in communication config to choose which Whisper client to use.

Because Parity’s implementation of Whisper is not compatible with Whisper v6, and therefore web3.js in its current form, the following changes have been made:
1. remove any functionality associated with launching a Parity Whisper process.
2. Warn the user when the Parity Whisper client has been opted for in the communication config.
3. Return an error for API calls when Parity Whisper client has been opted for in the communication config.
4. Update Cockpit’s Communication module to show errors returned from API calls.
5. Update the messaging configuration documentation for the new communication client option.
2019-12-11 11:12:18 -05:00
Pascal Precht 446197baff fix(@embark/blockchain): make disabling blockchain feature work
Users can turn of blockchain support if they want to using the blockchain.js
configuration. In practice however, this has never properly worked as several
places in Embark's codebase weren't actually honoring that configuration value.

This commit introduces the necessary changes so that disabling blockchain support will:

No longer generate blockchain related EmbarkJS artifacts
No longer try to deploy Smart Contracts but still compile them
2019-12-11 11:08:13 -05:00
Jonathan Rainville b82a240933 fix(@embark/test): fix using --node option in tests 2019-12-11 11:05:12 -05:00
Jonathan Rainville eae97dee4f fix(@embark/proxy): fix conflict for WS port in the proxy
This error arose when using tests parallel to Embark
2019-12-11 11:05:12 -05:00
emizzle db0e45e96e chore(@embark/site): Add `—template` deprecation notice. 2019-12-11 09:39:20 -05:00
Pascal Precht 0c5984c66d docs: clarify supported node version 2019-12-10 12:36:08 +01:00
Pascal Precht 1c12fde7a0
article: fix broken asset reference 2019-12-09 20:56:02 +01:00
Robin Percy 9436d71626
article: add web3 intro article 2019-12-09 20:37:31 +01:00
Pascal Precht 2ae46640e9 feat(@embarkjs/ens): Introduce `dappConnection` configuration for namesystem
This commit removes the need for `EmbarkJS.onReady()` and `EmbarkJS.Blockchain.blockchainConnector` APIs
in the ENS provider implementation and instead relies purely on vanilla `Web3`. This comes
with the effect that `EmbarkJS.Names` needs to figure out itself what to connect
to, as well as when a connection has been established.

To make that possible, `EmbarkJS.Names` now implements a similar algorithm to
`EmbarkJS.Blockchain` that tries to connect different endpoint, given a `dappConnection`
configuration.

If no `dappConnection` configuration is given via `namesystem.json`, Embark will fallback
to the same connection list that's provided in `contracts.js|json`.

wip
2019-12-09 12:07:03 +01:00
Iuri Matias 37ae942b99 chore(release): 5.0.0-alpha.3 2019-12-06 06:15:07 -05:00
Michael Bradley, Jr 6044576ca0 refactor(@embark/core): spec embark-whisper-* as deps of embark-core instead of embark
It is unnecessary and not a good idea for `packages/embark` to provide
dependencies to other monorepo packages via any kind of transitive dependency
relationship. In this case, `embark` depended on `embark-core` and
`embark-core` needs `embark-whisper-*` packages but it's `embark` that supplies
those packages indirectly. It works out in the monorepo, *probably* in
production too, but we need to move away from that pattern completely.
2019-12-05 18:47:01 -05:00
Michael Bradley, Jr a5d06509a3 fix(@embark/core): spec embark-rpc-manager as a dependency 2019-12-05 18:03:53 -05:00
Iuri Matias 6efe791cfd chore(release): 5.0.0-alpha.2 2019-12-05 15:03:09 -05:00
Michael Bradley, Jr 6bb673ef87 style(@cockpit/utils): remove stray type annotation 2019-12-03 11:05:27 -06:00
dependabot-preview[bot] 63cb420351 build(deps-dev): bump eslint-config-hexo from 3.0.0 to 4.0.0 in /site
Bumps [eslint-config-hexo](https://github.com/hexojs/eslint-config-hexo) from 3.0.0 to 4.0.0.
- [Release notes](https://github.com/hexojs/eslint-config-hexo/releases)
- [Commits](https://github.com/hexojs/eslint-config-hexo/compare/3.0.0...4.0.0)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-12-02 08:13:02 -06:00
dependabot-preview[bot] 49ace3f0e2 build(deps-dev): bump eslint from 6.7.1 to 6.7.2 in /site
Bumps [eslint](https://github.com/eslint/eslint) from 6.7.1 to 6.7.2.
- [Release notes](https://github.com/eslint/eslint/releases)
- [Changelog](https://github.com/eslint/eslint/blob/master/CHANGELOG.md)
- [Commits](https://github.com/eslint/eslint/compare/v6.7.1...v6.7.2)

Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2019-12-02 07:59:14 -06:00
Pascal Precht 47df65528a
article: add part 3 of crystal vs nim article series 2019-12-02 12:26:00 +01:00
Pascal Precht 5ef9a0148e
article: add credits 2019-12-02 12:25:48 +01:00
Michael Bradley, Jr 3a3182076e build(deps-dev): bump remaining @storybook/* packages from 5.2.5 to 5.2.7 2019-11-30 15:53:19 -06:00