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.
For payable methods inside of the contract interatction section of cockpit, the value input has been updated to pass wei to the API. The input field now accepts value like `100 ether` or 25 szabo`. The value entered is automatically converted to wei and shown to the user in real time.
Additionally, the input is validated for a correct value, with an error shown to the user for incorrectly entered values.
A tooltip has been added to help the user enter correct values.
UI updates can be seen in video here: https://monosnap.com/file/642cHH2HxDeiFLzB2VLqHP9GuqoRfz
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 pull-request upgrades `ethereumjs-wallet`, which has upgraded the underlying dependency on scrypt.js to 0.3.0, making scrypt an optional dependency and offering a pure JS version as a fallback.
The reasoning behind this is that scrypt is problematic to install in some systems, particularly those that don't have node-gyp setup and we have seen some weird issues when installing with elevated privileges (i.e. `sudo npm install -g scrypt`)
Embark API server's development proxy from port 55555 to 3000 was attempting to
inappropriately forward an `/embark-api/` endpoint for the blockchain process
logs to Create React App's development server. Why it was only happening for
the one endpoint is not known but probably has to do with timing around
registration of the API server's express routes.
The problem can be fixed with a one-line `filter:` function in the options for
`express-http-proxy`. However, it was realized that to fix an unrelated
problem, whereby the proxy doesn't forward websockets to CRA such that hot
reload doesn't work when accessing `embark-ui` in development on port 55555, a
switch to `http-proxy-middleware` would be required. That was quickly
attempted (easy switch) but there are outstanding [difficulties][bug] with
`webpack-dev-server` and `node-http-proxy` that cause CRA to crash.
Switch strategies and refactor the API module to serve a page on port 55555 (in
development only) that alerts the developer `embark-ui` should be accessed on
port 3000. The page redirects (client-side) after 10 seconds, with URL query
params and/or hash preserved. A future version could instead do client-side
polling of port 3000 with `fetch` and then redirect only once it's
available. The reason for not redirecting immediately is that the intermediate
page makes it more obvious what needs to be done, e.g. CRA dev server may need
to be started with `yarn start`.
[bug]: https://github.com/webpack/webpack-dev-server/issues/1642
Make tabs draggable so they can be arranged how the user would like.
The dragging functionality locks the tabs to the parent container.
Support for multiple rows of tabs.
Styling updates for selected tabs.
Implement a `/*` server-side catch-all route for Cockpit that loads Cockpit's
`index.html`.
This change is necessary with intent to disable offline-first behavior in
production builds of Cockpit. Cockpit's service worker effectively translates
server-side route unavailability into client-side behaviors of
connected-react-router. When the service worker is unregistered the same will
be accomplished via the server-side catch-all route.
Implement fallback pages for when embark is in the monorepo but Cockpit's
Create React App development server isn't yet started or isn't yet responsive.
Implement a fallback page for when the static build of Cockpit is missing. When
embark is in the monorepo, give instructions for building Cockpit. Otherwise,
report that the distribution is broken.
Deprecate the environment variable `EMBARK_DEVELOPMENT` in favor of
`EMBARK_UI_STATIC`. Unless the latter is truthy at runtime, when embark is in
the monorepo the CRA dev server of Cockpit will be accessible at
`localhost:55555` via proxied requests to `localhost:3000`. The deprecation is
not a breaking change as `EMBARK_DEVELOPMENT` / `EMBARK_UI_STATIC` are not
relevant to normal users, but only to developers working on embark itself.
Bump `express-http-proxy` to the latest version.
`"rxjs"` is [preferable][rxjs-pkg-name] in a CommonJS context,
e.g. node. Existing embark code is `require`-ing from the unscoped package
name, which worked in the monorepo because some other dependency specifies
`"rxjs"` and yarn hoists it to the root of the workspace. In a production
install of embark, though, `require('rxjs')` was failing.
[rxjs-pkg-name]: https://github.com/ReactiveX/rxjs/issues/2577
Previously, templates were in a subdirectory of `packages/embark`. Reorganize
them so that they are member packages of the monorepo. This allows them to
cleanly depend on other members of the monorepo,
e.g. `embarkjs-connector-web3`.
It is desirable for the templates, in the context of the monorepo, to specify
embark as a dependency, to take advantage of `npx embark test` (and it's a
"forward looking" setup re: how we plan to evolve embark). However, if embark
were to specify the template packages as dependencies a circular relationship
would be introduced, which is [unsupported by Lerna][circular]. Therefore,
revise the template generator so that all templates are resolved / fetched at
runtime, i.e. `boilerplate`, `demo`, and `simple` are no longer
"built-ins" *per se*. This change won't be apparent to embark's users, but it
does mean that the template generator won't work (in a production install of
embark) if it can't connect to the npm registry, i.e. when the user runs
`embark demo` or `embark new [--simple]`. When embark is inside the monorepo,
templates are resolved and copied from the yarn workspace rather than being
fetched from the registry, which is convenient for development. Also, any
template dependencies that are members of the monorepo are linked into the
copied template's `node_modules` rather than being installed from the registry,
again for convenience. During template generation, remove scripts and
dependencies that pertain only to membership in the monorepo; for now, that
involves removing embark as a dependency since we're not quite ready for that
arrangement to be the default, i.e. outside of the monorepo.
Refactor the root scripts so that more of them can consistently be used with
Lerna's filter options, e.g. `--scope` and `--ignore`. "Combo" scripts that
don't support filtering generally have a `:full` postfix.
Flip `clean` and `reset` scripts at the root and in the member packages for
consistency re: Lerna's notion of `clean` and embark's notion of `reset`. Have
each package run its `reset` script when its `clean` script is invoked (and
that's all for now), relying on `lerna clean` to delete packages'
`node_modules` in view of how Lerna's topological sorting works.
Lift the implementation of `embark reset` into a private package in
`packages/embark-reset` and make it a bundled dependency of embark. Packages in
`dapps/*` depend on `embark-reset` directly and make use of it with `npx
embark-reset` (but only in monorepo context). This removes a "wart" where
reboots could show errors when embark's sources aren't already built in
`packages/embark/dist`. Users will not notice any difference since `embark
reset` works as before, transparently making use of the `embark-reset`
package. The only downside to having it be a bundled dependency of embark is
that bundled deps have all of their `node_modules` included in the tarball
built with `npm pack` (that's why having the templates as bundled dependencies
of embark isn't a viable approach). However, `embark-reset` only has one
dependency, `rimraf`, which is a tiny module, so the cost seems acceptable.
As part of the reorganization, move `test_dapps` into `dapps/tests` and
`packages/embark/templates` into `dapps/templates`. Keep the directory names
short but revise the package names to facilitate simple filtering with
`embark-dapp-*`. Consolidate `.yarnrc` and `.gitignore` and clean up some
redundant ignore listings.
Scripts run with `--scope embark-dapp-*` use `--concurrency=1` to avoid
conflicts that could arise over network ports. The `ci:full` and `qa:full`
scripts use `--concurrency=1` in all scopes, for two reasons: resource
limitations on Travis and AppVeyor result in slower runs with concurrency >1,
and if something fails in those contexts it's easier to see what went wrong
when Lerna's output isn't interleaved from a bunch of scripts in `packages/*`.
Bump the Lerna version.
[circular]: https://github.com/lerna/lerna/issues/1198#issuecomment-442278902
