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
Michael Bradley, Jr
EmbarkBot
Pascal Precht
Iuri Matias
Jonathan Rainville
dependabot-preview[bot]