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`.
`embark-snark` has been updated such that it can be used, in conjunction with `embarkjs-snark`, in the console, and in the DApp.
This could, for example, be used to build a dapp like https://tornado.cash.
Please see the README for usage instructions.
Updated tests were excluded in this PR as a consideration for time already spent on getting this library completed. Tests should be updated in a future PR.
chore: make basic-pipeline an optional plugin
chore: make basic-pipeline an optional plugin
chore: make basic-pipeline an optional plugin
chore: make basic-pipeline an optional plugin
chore: make basic-pipeline an optional plugin
chore: make basic-pipeline an optional plugin
chore: make basic-pipeline an optional plugin
fixes
address code review
fix linter issue
fix missing param
fix binding
remove pipeline warning
remove unused var
feat: support selecting what library to generate artifacts
feat: support selecting what library to generate artifacts
feat: support selecting what library to generate artifacts
feat: support selecting what library to generate artifacts
working web3 artifacts
remove unnecessary request
address code review issues
fixes
update tests
WIP: add index.js in packages/plugins/embarkjs/
This is a pattern established in #2285
remove comment
fix some code review issues
This commit introduces support for using `embark.config.js` to calculate the
embark configuration object that is otherwise provided via `embark.json`.
If an `embark.config.js` file is present, it will be used over the
`embark.json` file. The `embark.config.js` module needs to export either an
object or a function that can be asynchronous and has to return or resolve with
an embark configuration object:
```js
// embark.config.js
module.exports = async function () {
let config = ...; // do lazy calculation of `embarkConfig`;
return config;
}
```
The signTypedData rpc method was broken, because it didn't check for
the node accounts, meaning that if you wanted to sign with a node
account that was unlocked, like in the tests, it would throw
Managing account details inside of the RPC Manager became a bit convulted and difficult to follow due to any web3 requests inside of an `RpcModifier` communicating over the proxy and therefore to other `RpcModifier`’s or itself. It also created cases where node accounts were duplicated by way of running the `eth_accounts` modifier multiple times (the first time getting accounts from the node and subsequent times getting accounts from the modified `eth_accounts` response.
This has been simplified by having the entry point of the `rpc-manager` (`index.js`) talk directly to the node via `web3`. This allowed account/nodeAccount management to also be handled by the entry point, removing the need for each individual `RpcModifier` from having to handle these account details. The result is a much more simplified and and much easier to maintain code for RPC Manager.
The cases for which accounts can be modified (via `personal_newAccount` RPC call, and via test configuration change) are now handled in one place (the entry point) and propagated to the each `RpcModifier`.
Add `blockchain:started` command to request when the blockchain has been started. In this case, this is needed so that we know when we can create a direct connection to the node, instead of the proxy (as is the case in almost all other modules).
Extend action timeout when in debug mode.
1. These changs have made the `RpcModifier` base class essentially useless, however, it has been kept in place because it will be used for future DRY improvements to the `rpc-manager`.
2. These changes have been tested with the following DApps:
- Demo
- Test DApp
- Contracts test DApp
- Teller
emizzle
Pascal Precht
Jonathan Rainville
Michael Bradley, Jr
EmbarkBot
Iuri Matias
dependabot-preview[bot]