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`.
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.
Effectively deprecate the `embarkjs-connector-web3` package but don't introduce
a breaking change by simply not loading the plugin if it's specified in a
DApp's `embark.json`. If the deprecated plugin is specified, display a message
indicating the plugin was ignored and suggesting it be removed from the
project's `embark.json` and `package.json`.
The webserver's job is to serve files generated by Embark's built-in pipeline,
however, since v4 users can choose they front-end tool to take care of building,
bundling and packing their DApps. Usually these tools come with a built-in
dev server as well.
Therefore, when the pipeline is turned off (which also soon will be the default),
there's not need start a webserver.
Upgrade chokidar to a version that's compatible with NodeJS v12.x.
Unfortunately, embark has other transitive dependencies that are not compatible
with v12.x, but upgrading chokidar is still a good step.
This package comes with a `setUpEnv()` function that can be called to
prepare Embark's environment variables for different process contexts.
This allows us to set up Embark's environment within a test runner context
without the requirement of importing `packages/embark/src/lib/core/env.js`,
which happens to set up those necessary environment variables as a side effect.
It's important that a path to `packages/embark`'s root is passed down to `setUpEnv()`
to ensure `EMBARK_PATH` gets the correct value.
E.g. within a package `embark-console`, `setUpEnv()` can be called within its tests
like the following:
```
// packages/embark-console/src/test/console.js
import { joinPath, setUpEnv } from 'embark-utils';
setUpEnv(joinPath(__dirname, '../../../embark'));
```
Here, `__dirname + '../../../embark'` ensures `EMBARK_PATH` points to the root
of `packages/embark`. This might look different in other contexts.
For example calling this function from a test file within `packages/embark`, this would
look like this:
```
// packages/embark/src/test/some_file.js
import { joinPath, setUpEnv } from 'embark-utils';
setUpEnv(joinPath(__dirname, '../../'));
```
If the `embark` cli is detected to be inside the monorepo, the template
generator yarn-links any template deps that are part of the monorepo into the
dapp. However, `embarkjs-connector-web3` now has a dependency on `embark-core`,
which in turn has a dependency on `embark-i18n`. That causes `npm install` to
fail inside the dapp because npm checks for deps of `embarkjs-connector-web3`
relative to the dapp instead of checking relative to the symlink. `yarn
install` does not suffer from that behavior so use it instead.
Move the debugger module to the `embark-debugger` package.
Handle case where `debug` is entered as a console command, and there is no transaction to be debugged.
add embark-i18n and mocha deps
This enables removing unnecessary `core/fs` dependencies which can be
replaced with `fs-extra`.
This commit also fixes a bug introduced in f868d1216d
where methods from `embark.fs` weren't available.
The reason for that is because we have several *Process instances
that are created through child process communication, specifically
process.send() APIs. Using those APIs, we can only send data structures
however, methods attached on any of those will get lost.
This is the case when sending embark.fs through process.send().
We still need fs in those places though, mostly because they are relying
on embarkPath and dappPath().
These places are now importing those functions from `embark-core`. Other
API such as writeFile or mkdirp() can be accessed through fs-extra
or fs modules.
