DApps generated with `new --simple` don't have a blockchain config so ensure
that the blockchain proxy and listener (dev_txs) use appropriate provider
settings when setting up web3.
Without these changes, in a fresh `embark new --simple` project the `embark
blockchain` command will encounter unhandled promise rejection with respect to
the proxy; `embark run` will encounter similar with respect to dev_txs.
Previously, when using "development embark" (i.e. `embark` command in the
monorepo) the template generator would always use `yarn install` to install a
template's dependencies. However, if a template relies on `package-lock.json`,
as is the case for `embark-create-react-dapp-template`, that behvaior can cause
serious problems. So, have the choice of install command depend not only on
whether we're using "development embark" but also whether the template has a
`package-lock.json` file.
NOTE: this change can probably result in problems given that `yarn install` and
`npm install` behave differently re: symlinks in `node_modules`. However, such
problems would never show up with production installs of the `embark`
packaage. Moreover, after dropping `embarkjs-connector-web3` we don't presently
have a situation where a monorepo package would be `yarn link`ed into an
instantiated template's `node_modules`. So, in effect, the changes introduced
in this PR allow existing templates to work correctly whether using production
or monorepo embark. The impending embark v5 refactor should deprecate `embark
new` in favor of the yet unfinished `embark init`.
When passing the name of a build pipeline that doesn't exist, e.g.
`embark run|build --pipeline foo`, `writeStats` would cause an unhandled
promise rejection because its config argument is falsy. Checking for that and
returning early from `writeStats` allows the `"no webpack config has the name
'foo'"` error to be reported correctly.
The ignore paths for the default webpack config and babel-loader-overrides
helper script weren't properly adjusted after the legacy pipeline was split-out
into its own package in the monorepo.
Upgrade all dependencies on web3/web3-* v1.0.0-beta.37 to v1.2.1.
Make various adjustments related to the previous convention of
`"web3": "1.0.0-beta"` in `embark.json` signifying that embark's own web3
dependency should be used in dapp builds.
Fix bugs in library manager, including a switch from using the
live-plugin-manager package to using npm in a child process to install
`"versions"` dependencies specified in `embark.json` when a specified version
doesn't match up with embark's own version for that package.
Avoid race conditions when installing `"versions"` by completing all installs
prior to starting other services. If an install fails, then after all the
installs have completed or failed the embark command will exit with error.
Change various comments and update docs to reflect the new default of web3
v1.2.1.
In https://github.com/embark-framework/embark/commit/87d92b6091 we've introduced a feature in our test runner
to report exact gas costs used when calling Smart Contract methods that
cause computation.
Embark keeps a list of deployed contracts in memory and for all transactions
happening during tests, it'll match them to the contracts that performed them
to produce the report logs.
Unfortunately, we've been [resetting that memory](https://github.com/embark-framework/embark/commit/87d92b6091#diff-92b4f79a0473160fe700440b1ced5204R140) of deployed contracts
after every test, making it practically impossible for Embark to find
matching contracts for any transactions, because contracts aren't necessarily
redeployed per spec, resulting in no additional transaction logs whatsoever.
This commit ensures that the memory is never erased and at the same time
ensures it's not leaking infinitely in case multiple contracts are
deployed multiple times in the same process over several specs.
We've introduced a regression in 536a4029ba where the default
`value` sent to payable Smart Contract methods is `-1`, resulting in errors as it's not
a valid value.