Make various related changes to templates, tests, etc. The methodology for
finding files that needed changes was to search through the whole monorepo for
the strings "solc" and "solidity" and then inspect the hits to see whether
changes were needed/appropriate.
Remove `solc` as a dependency in `packages/embark/package.json` so that it's
only a proper dependency in `packages/plugins/solidity/package.json`. Adjust
how the "bundled" `solc` package's version is determined, i.e. inspect the
`package.json` of `embark-solidity` instead of `embark`.
When `solc`'s version is `>=0.6.0` use the [new callback API][api].
[api]: https://github.com/ethereum/solc-js/blob/master/README.md#example-usage-with-import-callback
Also, in `dapps/tests/contracts` move the `this.timeout(0);` inside the
`it(...)` for the expensive gas esimation (involving
`SimpleStorage.methods.set`) because it otherwise doesn't seem to have an
effect on the default 15 second timeout.
Remove the `<12.0.0` restriction re: Node.js version in the `"engines"`
settings for all the packages in the monorepo that had that restriction.
Add missing `"engines"` settings in `packages/plugins/snark/package.json`.
Adjust the Azure Pipelines config to include builds for Node.js v12.x and
v13.x.
Bump `solc` to `0.4.26` in `dapps/tests/app` and `dapps/tests/contracts`. It
was discovered that older versions suffered a fatal `Maximum call stack size
exceeded` error when run on Windows with Node.js v12.x or newer. Display a
warning re: the bad combo (solc version + Windows + Node version) if it's
detected at runtime.
Adjust the root `yarn.lock` so that the `sha3` transitive dependency resolves
to a newer version that is compatible with Node v13.x.
This commit adds two new configuration settings for Smart Contract configuration:
- `interfaces` - Any Smart Contract that represent an interface or is used for inheritance
- `libraries` - Any Smart Contract that is used as a library
This makes the configuration less redundant in cases where otherwise the `deploy`
property has been set to `false`, such as:
```
deploy: {
Ownable: {
deploy: false
},
...
}
```
The above can now be done via:
```
interfaces: ['Ownable'],
deploy: {
...
}
```
## Problem
When using `embark test —node=embark` with the test app, the test that listens for contract events would always fail after timing out. Funnily enough, after the timeout, the subsequent test would run, executing a method that would ulimately fire the event listened for in the previous test, causing the second test to fail as well.
## Solution (workaround)
Update the contract events listener test in the test app to execute the `set2` method twice, successfully working around the issue.
## NOTES
The cause of the issue is unknown and why the workaround works is also unknown.
This change works with both `embark test` and `embark test —node=embark`.
This commit introduces a new `global.getEvmVersion()` that can be used to
conditionally run tests, such as when tests rely on RPC APIs that are only
available in specific evm nodes.
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.
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`.
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
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.
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
Client traffic with the communication provider node, e.g. a whisper node, is
not proxied so make the default port 8547 instead of 8557. It's not a technical
problem for it to be 8557, but our convention to present has been for 855*
ports to be proxied while the upstream is an 854* port.
Update the boilerplate and demo templates to match.
Improve the reliability of the expiration unit test in the test dapp by explicitly setting the `block.timestamp` and comparing an expiration value against that.
This improves on the current implementation that relies on time passed which varies depending on the speed of unit tests run (CPU speed, logs shown, etc).
When `eth_unsubscribe` is received in the proxy, ensure this request is forwarded through on the correct socket (the same socket that was used for the corresponding `eth_subscribe`).
Move subscription handling for `eth_subscribe` and `eth_unsubscribe` to RpcModifiers (in `rpc-manager` package).
For each `eth_subscribe` request, a new `RequestManager` is created. Since the endpoint property on the proxy class was updated to be a provider, the same provider was being assigned to each new `RequestManager` and thus creating multiple event handlers for each subscription created. To circumvent this, we are now creating a new provider for each `RequestManager`.
Co-authored-by: Pascal Precht <pascal.precht@googlemail.com>
BREAKING CHANGE:
Related to #1985. Prior to Embark's minimum supported version of Node.js being
bumped to to 10.17.0, Embark was incompatible with any relatively recent
release of the `ipfs-http-client` package.
While *internal* changes are needed re: ipfs's `Buffer` export for
e.g. `embark_demo` to function correctly *(and this PR makes those changes)*,
Embark otherwise runs/tests okay.
Keep in mind #2033.
However, if a dApp author were to explicitly `require('ifps-api')` in the
front-end that wouldn't work as before; and swapping `"ipfs-http-client"` for
`"ipfs-api"` might also not be enough — there are API changes that dApp authors
would need to consider, regardless of Embark presently supplying the dependency
and EmbarkJS wrapping around it.
Closes#1994.
Iuri Matias
Michael Bradley, Jr
EmbarkBot
dependabot-preview[bot]
Jonathan Rainville
Pascal Precht
emizzle