Even when the storage config sets storage to disabled, upload should still be allowed, as uploaded dapps should have the ability to NOT use storage once uploaded.
Prior to this commit, `Console` would only be rendered when Embark's API returns
at least one registered process from `/embark-api/processes`.
`Console` itself would then add another processes "embark" resulting in two tabs
with console output. This used to work fine because Embark always registered
at least a blockchain process.
In cd934f8157 however, this has changed.
With Ganache being the default blockchain, there's no longer a processes registered for this
service, resulting in an empty list for `processes` inside Cockpit, causing `Console` not to render
at all. Which also means the `embark` process logs aren't rendered either.
This commit removes the requirement of `processes` being non-empty so that embark process
logs are always shown.
It also fixes `Console` to updates its own `processes` state when its properties change.
This is needed because it's no longer guarded by `DataWrapper`, which previously ensured
`Console` is only rendered when there are processes.
Kudos to @jrainville for helping me cracking this nut.
In https://github.com/embarklabs/embark/pull/2330#discussion_r389906144 we've changed the `solc` plugin to read its
`pluginConfig` from `embark.config`. This was done under the assumption that
the `embark.config` is always properly populated with a dedicated `pluginConfig`.
In our testing environment we pass `Embark` objects to plugins, while in reality, we pass `Plugin` instances.
These two are different in nature, so relying on `embark.config` inside the plugin seemed the
most pragmatic way forward without introducing a bigger refactoring in the testing APIs.
Unfortunately it turned out that `embark.config` isn't populated with a `pluginConfig`
which essentially caused it to break apps.
This commit reverts that change done in the mentioned PR and patches the Embark testing
API to behave like a `Plugin` while still being an `Embark` instance.
Both, `httpProxy` and `wsProxy` inside `Proxymanager` have been assigned
the value of `new Proxy(...).serve()` which is an instance of `express`.
This was wrong and causes runtime errors when proxies are being stopped as
they don't have a `stop()` API.
In dev mode, accounts are funded per the blockchain accounts config. In specific situations, there may not be enough funds on the account returned by `eth_coinbase`. In that case, and in the case when `eth_coinbase` returns `0x0` (or equivalent), loop through all accounts and find the one that has the most funds and use that as the coinbase account.
Fix an issue with storage process launcher hanging when changing environments. This occurred most frequently when the IPFS process was forced to restart due to the change in environment. Change in enviroment can be considered:
1. `embark run env1`
2. `Ctrl+c`
3. `embark run env2`
Add support for *connecting to* Quorum blockchains. This plugin will not start a Quorum node or nodes automatically as Embark does with other chains.
This plugins supports deploying contracts publically and privately using the Tessera private transaction manager.
This plugin supports sending of public and private transactions using the Tessera private transaction manager.
Add ability to skip bytecode checking as part of the contract deployment process. Instruct the deployer to skip checking if the contract bytecode exists on-chain before deploying the contract. This is important in the case of having many private nodes in a network because if a contract is deployed privately to node 1 and 7, running Embark on node 2 should skip the bytecode check as the contract *is not* deployed on node 2, nor do we want it deployed on node 2. If the bytecode check was in place, Embark would have deployed it to node 2 and therefore not adhered to the privacy needs.
Add Ethereum contract deployer for Quorum, allowing for deploying of public and private contracts using `privateFor` and `privateFrom` (see Contract config updates below).
Add web3 extensions enabling specific functionality for Quorum. Extensions includes those provided by [`quorum-js`](https://github.com/jpmorganchase/quorum.js), as well as some custom monkeypatches that override web3 method output formatting, including:
- web3.eth.getBlock
- web3.eth.getTransaction
- web3.eth.getTransactionReceipt
- web3.eth.decodeParameters
DApps wishing to take advantage of these overrides will need to patch web3 as follows:
```
import {patchWeb3} from "embark-quorum";
import Web3 from "web3";
let web3 = new Web3(...);
web3 = patchWeb3(web3);
```
Add support for sending a raw private transaction in the Quorum network. This includes running actions from the proxy after an `eth_sendTransaction` RPC request has been transformed in to `eth_sendRawTransaction` after being signed.
fix(@embark/transaction-logger): Fix bug when sending a 0-value transaction.
Add `originalRequest` to the proxy when modifying `eth_sendTransaction` to `eth_sendRawTransaction`, so that the original transaction parameters (including `privateFor` and `privateFrom`) can be used to sign a raw private transaction in the `eth_sendRawTransaction` action.
Added the following properties on to blockchain config:
- *`client`* `{boolean}` - Allows `quorum` to be specified as the blockchain client
- *`clientConfig/tesseraPrivateUrl`* `{string}` - URL of the Tessera private transaction manager
```
client: "quorum",
clientConfig: {
tesseraPrivateUrl: "http://localhost:9081" // URL of the Tessera private transaction manager
}
```
Added the following properties to the contracts config:
- *`skipBytecodeCheck`* `{boolean}` - Instructs the deployer to skip checking if the bytecode of the contract exists on the chain before deploying the contract. This is important in the case of having many private nodes in a network because if a contract is deployed privately to node 1 and 7, running Embark on node 2 should skip the bytecode check as the contract *is not* deployed on node 2, nor do we want it deployed on node 2. If the bytecode check was in place, Embark would have deployed it to node 2 and therefore not adhered to the privacy needs.
- *`privateFor`* `{string[]}` - When sending a private transaction, an array of the recipient nodes' base64-encoded public keys.
- *`privateFrom`* `{string}` - When sending a private transaction, the sending party's base64-encoded public key to use
```
environment: {
deploy: {
SimpleStorage: {
skipBytecodeCheck: true,
privateFor: ["ROAZBWtSacxXQrOe3FGAqJDyJjFePR5ce4TSIzmJ0Bc"],
privateFrom: "BULeR8JyUWhiuuCMU/HLA0Q5pzkYT+cHII3ZKBey3Bo="
}
}
},
```
- *`proxy:endpoint:http:get`* - get the HTTP endpoint of the proxy regardless of blockchain settings
- *`proxy:endpoint:ws:get`* - get the WS endpoint of the proxy regardless of blockchain settings
- *`runcode:register:<variable>`* - when variables are registered in the console using `runcode:register`, actions with the name of the variable (ie `runcode:register:web3`) will be run *before* the variable is actually registered in the console. This allows a variable to be modified by plugins before being registered in the console.
We've made the `basic-pipeline` optional in 948956ab1f but are still
trying to load the pipeline module group in inside the `build` cmd.
This breaks at runtime as no such module group exists anymore.
When using accounts, yes those account are always the same, but
ganache still creates it's own accounts, with a random mnemonic.
So Plugins that rely on the node accounts were crashing on second
run, because the node accounts were no longer the same.
When making `basic-pipeline` in 948956ab1f we've introduced a regression
and with this fix, a behaviour change as well::
1. The `webpackConfigName` passed to `Engine` is completely ignored, caused it to be
`undefined` down the line when the plugin tries to do its work (we essentially broke bundling)
2. With that configuration being ignored, we need a new way to make this configurable.
Since `basic-pipeline` is now a true plugin, it makes sense for itself to have configuration
options for that, while still providing decent defaults.
3. The trickly thing is that `webpackConfigName` used to have different values per command.
For example `build` used to use `production` while `run` used `development` as config.
4. This commit introduces new configuration options for `basic-pipeline` that lets users configure
the `webpackConfigName` per environment:
```json
// embark.json
{
...
"plugins": {
"embark-basic-pipeline": {
"development": {
webpackConfigName: "development"
},
"production": {
webpackConfigName: "production"
}
}
}
}
```
^ These are also the defaults. So not providing this configuration will make
Embark imply it.
Notice that this does not account for the "different config per command" case.
This means `embark build` will also use `development` by default.
Prior to this commit and the one mentioned above, the `webpackConfigName` was configurable
through the CMD `--pipeline` option. Since this a) no longer a built-in feature
and b) ignored at the moment anyways, I've removed the `--pipeline` options
from all commands as well.
BREAKING CHANGES
The commands `embark eject-webpack` and `embark eject-build-config` are no longer available.
The `--pipeline` option has been removed from all commands that used to support it.
When taking a bare-minimum truffle project, created from the [`metacoin` truffle box](https://github.com/truffle-box/metacoin-box), there were only two steps that needed to happen as a prerequisite:
1. First, run `embark init`, creating a default `embark.json`
2. Second, run `npm init`, creating a default `package.json`.
Trying to run `embark run` before those prequisites would error with appropriate directions in the console, guiding the user to run those steps explicitly.
After running these two steps, Embark would hang waiting for the namesystem plugin to come up.
Changing the default namesystem config to disabled allows Embark to start up successfully without hanging.
The rationale behind this decision is that if `embark.json` doesn’t exist, then we cannot expect that the namesystem plugin will be installed in the project either, and thefore its default value should be disabled.
Refactor `scripts/check-yarn-lock.js` to use a dynamically calculated
blacklist (`npx lerna ls --all --json`) instead of a hard-coded whitelist to
improve accuracy and reduce future maintenance.
Range specifiers for intra-monorepo dependencies can, because of nightly or
stable releases, get out of sync between PR branches and `master`. In many
cases, what then happens is that yarn can't satisfy the dep range with the
version in the monorepo, so it installs from the registry and updates
`yarn.lock` accordingly. We have a `check-yarn-lock.js` script (`yarn cylock`)
that detects the situation and prevents CI from passing. However, to date the
problem has to be fixed manually.
Implement a script that fixes the problem by scanning all the `package.json`
files and updating mismatched ranges.
It's best to run the script *after* rebasing against `master`.
fix(@embark/blockchain): Add callback to `blockchain:node:register` and `blockchain:client:register`
Add unit tests for the stack/blockchain and update supporting API documentation in the Wiki.
Add injectables `Web3` and `warnIfPackageNotDefinedLocally` to stack/blockchain so that those functions can be tested properly.
Update stack/blockchain dependencies in `package.json`.
dependabot[bot]
EmbarkBot
Ricardo Guilherme Schmidt
Michael Bradley, Jr
Pascal Precht
emizzle
Jonathan Rainville
emizzle