Commit Graph

104 Commits

Author SHA1 Message Date
Michael Bradley, Jr fbeea47a6e fix(embark-ui): correctly calculate which transactions to display
Revise calculations related to transactions and pagination in the transactions
explorer and explorers overview.

Make the number of transactions to display per page configurable and set it to
3 in the explorers overview. Display a "No transactions..." message instead of
"0" when there are no transactions to display.

Introduce a `blocksFull` prop, action, api, etc. for calculating lists of
transactions relative to block objects that contain full transaction objects
instead of hash strings (the function backing the blocks endpoint already
supports that) and transaction receipts. In the future, the receipts can be
used to filter out constructor transactions for silent contracts.

Make pagination display conditional within the blocks explorer, same as in the
transactions explorer.
2019-03-15 15:25:56 -05:00
Jonathan Rainville b1881719e0 Fix tests (CI) and debug button (#1443)
* fix(embark/tests): fix tests by not tampering with the contract addr

* fix(cockpit/debugButtong): use deployedAddress instead address
2019-03-15 16:22:24 -04:00
Michael Bradley f60c979c75 refactor(embark-ui): filter silent contracts from contracts listings (#1444)
Filter silent contracts in the views that display contracts lists rather than
with `formatContractForDisplay` because the old approach prevents interaction
with a silent contract if a link to it is followed from the blocks or
transactions explorer, which is not desirable.
2019-03-15 16:22:15 -04:00
Michael Bradley, Jr 9afdbd9848 refactor(embark-ui): improve cockpit's contracts explorer
Rename contract "Transactions" tab to "Log". Display and allow filtering of all
contract methods. Disable debug button for pure/view functions and the
constructor.

Revise the filtering logic so that filters are combined together. Make the
status filter a drop down menu like the others.

Revise styling for consistent row height, alignment of text, and button sizes;
use a monospaced font in some cases to achieve the effect.

Handle enter/return correctly in forms within a contract's Interact tab.

Remove event rows from a contract's Interact tab.

Track pure/view calls in the blockchain proxy so they can be logged server-side
by console listener and reported in Cockpit within a contract's Log tab.

Eliminate double logging in the contracts manager. Ensure contracts deployed on
a fresh `embark run` have an `address` / `deployedAddress` property.
2019-03-15 12:03:52 -05:00
Andre Medeiros b15467f64a feature: decode raw transactions in tx decoder 2019-03-15 12:28:21 -04:00
Andre Medeiros 2cc0d305e6 fix: pressing enter on "Display additional results" does the expected thing 2019-03-14 14:13:35 -04:00
Jonathan Rainville 5816a79ae6 fix(cockpit/sidebar): fix closed sidebar in the dark-theme 2019-03-14 14:01:57 -04:00
Iuri Matias 785edf4c9d use e.key instead of e.which 2019-03-14 14:01:28 -04:00
emizzle 8b7a374313 fix(@embark/cockpit): Utils/Communications handle enter
Handle enter pressed when listening to channels and sending messages.
2019-03-14 14:01:28 -04:00
Michael Bradley, Jr cc8363a94b fix(embark-ui): correctly calculate which blocks to display
Revise calculations related to block numbers and pagination in the blocks
explorer and explorers overview.

Make the number of blocks to display per page configurable and set it to 5 in
the explorers overview.
2019-03-13 12:35:12 -04:00
Jonathan Rainville dddc9d0cf6 fix(cockpit/firefox): fix bug with entities in firefox (ordering) 2019-03-13 12:13:52 -04:00
Jonathan Rainville 447f3eda06 fix(cockpit/transactions): enable filtering constructor 2019-03-13 11:08:20 -04:00
Jonathan Rainville a341a4f3b2 fix(cockpit/console): replace br with backslash n 2019-03-13 10:21:10 -04:00
Jonathan Rainville 71da423e4e fix(cockpit/console): increase number of suggestions 2019-03-13 10:21:01 -04:00
Michael Bradley, Jr 5418f16082 feat: normalize README and package.json bugs, homepage, description
Make changes by running these commands in the root of the monorepo:

**bugs**
```shell
npx lerna exec --concurrency 1 --stream -- \
    'DIRPATH=$(realpath $PWD --relative-to=$LERNA_ROOT_PATH); \
    npx json -I -f package.json -e "this.bugs=\
        \"https://github.com/embark-framework/embark/issues\""'
```

**homepage**
```shell
npx lerna exec --concurrency 1 --stream -- \
    'DIRPATH=$(realpath $PWD --relative-to=$LERNA_ROOT_PATH); \
    npx json -I -f package.json -e "this.homepage=\
        \"https://github.com/embark-framework/embark/tree/master/${DIRPATH}#readme\""'
```

Don't commit changes to private packages, with the exceptions of embark-typings
and embark-reset because those may switch from private to public, and also
because the latter will be included in `node_modules` of embark even if it is
private since embark-reset is presently a bundled dependency of embark.

Don't include the homepage and bugs fields in dapps generated from the template
packages, except for the demo. Set those dapps' description field to an empty
string.

Ensure every package (inc. private packages) has a description.

Ensure every package (inc. private packages) has a README that begins with:

```markdown
`[pkgJson.name]`
================

> [pkgJson.description]

Visit [embark.status.im](https://embark.status.im/) to get started with
[Embark](https://github.com/embark-framework/embark).
```

Don't include the README in dapps generated from the template packages, except
for the demo.
2019-03-12 09:17:33 -04:00
Michael Bradley, Jr df0064f1a9 build: use package.json "files" instead of .npmignore
`package.json` allows for a [`"files"` whitelist][files] to be specified as an
alternative to a top-level `.npmignore` within a package root. Maintaining
whitelists is generally easier and less error-prone than maintaining
blacklists, so implement a `"files"` list for all non-private packages in the
monorepo and remove unneeded `.npmignore` files.

Switch `embark-reset` from being a private package to one that will be
published, adjust the workspace's `"nohoist"` setting accordingly, and no
longer specify `embark-reset` as a bundled dependency of `packages/embark`. I
originally thought there might be a good reason not to publish it, but I no
longer think so.

Remove unnecessary LICENSE files in `packages/{embark,embark-ui}` since Lerna
will automatically copy the root LICENSE into any packages lacking that file,
i.e. before tarballs are packed and published to the NPM registry.

Change the `"author"` field of `packages/embarkjs-connector-web3` to match the
other packages, i.e. such that it matches the copyright assignment in the root
LICENSE. If that's not a desirable thing to do, then instead that package can
have a separate LICENSE file that has a copyright assignment for `"Jonathan
Rainville"`.

Supply some missing `.npmrc` files in `packages/*`.

[files]: https://docs.npmjs.com/files/package.json#files
2019-03-12 07:50:25 -04:00
Jonathan Rainville cba7c85242 fix(cockpit/transactions): fix a typo in the transactions page 2019-03-11 18:28:19 -04:00
Jonathan Rainville 74847ee323 feat(cockpit/transaction): display a link for contracts and accounts 2019-03-11 18:28:19 -04:00
Jonathan Rainville 99dcd785bc fix(cockpit/contract): remove contract profiling and use functions 2019-03-11 18:21:54 -04:00
Michael Bradley, Jr a9c5e1ade5 feat: add repository.directory field to package.json
See: https://github.com/npm/rfcs/blob/latest/implemented/0010-monorepo-subdirectory-declaration.md

Make changes by running this command in the root of the monorepo:

```shell
npx lerna exec --concurrency 1 --stream -- \
    'DIRPATH=$(realpath $PWD --relative-to=$LERNA_ROOT_PATH); \
    npx json -I -f package.json -e \
    "this.repository=\
        {\"directory\": \"$DIRPATH\", \
         \"type\": \"git\", \
         \"url\": \"https://github.com/embark-framework/embark.git\"}"'
```

Don't commit changes to private packages, with the exceptions of embark-typings
and embark-reset because those may switch from private to public, and also
because the latter will be included in `node_modules` of embark even if it is
private since embark-reset is presently a bundled dependency of embark.

Don't include the repository field in dapps generated from the template
packages, except for the demo.
2019-03-11 18:21:24 -04:00
Andre Medeiros f12ca22edb fix: limit cockpit editor file size 2019-03-11 18:20:56 -04:00
Andre Medeiros 616af6d765 fix: validate whisper channel name in communication tab 2019-03-11 18:19:00 -04:00
Andre Medeiros 4340a9b482 fix: editor wasn't saving changes 2019-03-11 18:18:52 -04:00
emizzle a6b15ae98f fix(@embark/cockpit): Switching between tabs resets logs
Switching between the two tabs shown on the Dashboard for the cockpit was removing some of the logs that were previously displayed. This was due to an overlap in `id`’s being assigned to the logs from different processes.

To alleviate this, the reducers has been updated to not only check `id` but also `process.name`.

Additionally, the reducer was updated so that the number of logs for **each process** is set to `ELEMENTS_LIMIT`. For example, our `ELEMENT_LIMIT` is currently set to `200` and it would have meant that the total number of process logs across all processes would have been capped at 200. The current changes in this PR allow for 400 total logs, given that we have two processes being monitored for logs.
2019-03-11 17:39:05 -04:00
emizzle 128ecd4c51 fix(@embark/core): Prevent unnecessary re-renderings
The services websocket was initiated in the AppContainer and causing all child components to continuously re-render every time there was a service check (which is effectively every second). In addition, the socket was never stopped when not needed (ie when the services component was unmounted).

Create a ServicesContainer that initiates the websocket as part of the container, and stops the socket when the container is unmounted.

Move the ContractsList to be part of the ContractsContainer with a `mode` switch.

Add Deployment page title and description.
2019-03-11 17:38:33 -04:00
Jonathan Rainville cc495c5cab hotfix(cockpit/editor): remove test alert 2019-03-11 16:00:26 -04:00
Jonathan Rainville c30c420ae8 fix(cockpit/editor): remove delay on tooltips
This caused issues when moving from one tooltip to the other
2019-03-11 09:05:49 -04:00
Jonathan Rainville 7720eac74f codacy fix 2019-03-11 09:05:15 -04:00
Jonathan Rainville ecdfd473df feat(cockpit/editor): add status messages for file operations 2019-03-11 09:05:15 -04:00
Jonathan Rainville 3f488e1d88 fix(cockpit/editor): add delete modal to confirm deletion
Also fix cases where modals closed for no reason
2019-03-11 09:04:45 -04:00
Jonathan Rainville da76c8d804 fix(cockpit/deployment): filter out silent contracts 2019-03-08 12:55:58 -05:00
Jonathan Rainville 0648824646 fix(cockpit/header): fix nav not highlighted for children pages 2019-03-08 12:55:05 -05:00
Jonathan Rainville 35648eefa0 fix(cockpit): fix converter inputs and copy-button position 2019-03-08 12:55:05 -05:00
Jonathan Rainville 359c28f5b5 fix(cockpit:editor): fix arrow not turning 2019-03-08 09:26:13 -05:00
Jonathan Rainville fac29e1601 revert console to only show cockpit results in cockpit 2019-03-08 08:54:30 -05:00
emizzle c233dbc7fb fix(@embark/core): Metamask + geth warning to enable regular txs
A console warning is meant to appear in the browser console when the dapp is connecting to web3 using metamask and the blockchain client is geth. The warning displays information telling the user they should enable regular transactions to prevent known issues regarding transactions getting stuck.

The issue fixed here pertained to `warnAboutMetamask` vs `warnIfMetamask` - maybe there was a change that introduced this issue upstream.

Additionally, enabling and disabling of regular transactions via an API endpoint did not

Add ability to stop regular txs via query string, and validate request parameters.
2019-03-08 12:41:13 +11:00
Jonathan Rainville 0e63d6bcf9 feat(cockpit/contracts): don't display contracts marked as silent 2019-03-05 16:21:39 -05:00
André Medeiros 58ab76d2ca
fix: format \n as <br> in cockpit console (#1385) 2019-03-05 14:29:57 -05:00
André Medeiros 913b4e1817
fix: upgrade packages with vulnerabilities (#1388) 2019-03-05 14:29:36 -05:00
André Medeiros 891174eda3
fix: cockpit search with tx hash shows tx page (#1386)
This issue was caused by a string to integer conversion. In JavaScript,
when converting a string that starts with `0` (which is the case for tx
hashes) to an integer using `parseInt` it will always yield 0. That,
combined with a block with number 0 would always return a block result
instead of the transaction.

```
> parseInt("0xluri", 10)
0
```

This PR checks if the resulting number equals the string that was
provided on top of checking for the block number.
2019-03-05 14:14:05 -05:00
Michael Bradley, Jr de0f02d00a build: make DApp templates member packages of the monorepo
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
2019-03-05 10:20:57 -06:00
emizzle f957ba55dd fix(@embark/cockpit): Fix decode transaction error
Reproduce:
1. Go to cockpit > transactions
2. Click a transaction
3. There will be a flicker of an error, then the decoded tx displays OK. Inspecting the network requests, there is a 500 error with a response of
```
AssertionError [ERR_ASSERTION]: invalid remainder
```
This error is also printed in the console.

The issue is that the transaction is not a raw transaction, so instead of trying to decode the non-raw transaction, the transaction can be decoded by web3.
2019-03-05 12:01:07 +11:00
Jonathan Rainville c708bad8bb chore(cockpit/estimator): always return an integer for getGasPrice 2019-02-26 13:01:50 -05:00
Jonathan Rainville 1759aac8aa fix(cockpit/estimator): make estimator clearer 2019-02-26 13:01:50 -05:00
Jonathan Rainville e3396417da feat(cockpit/console): display cmds from cockpit in embark console 2019-02-26 12:55:58 -05:00
Anthony Laibe f5f610d520 fix(embark-ui): pagination 2019-02-26 14:37:58 +00:00
Iuri Matias 017ec59b23 chore (@embark/embark-ui) clarify token login in cockpit 2019-02-25 15:03:46 -05:00
Iuri Matias 5bb0d7ceae chore (@embark/embark-ui) clarify placeholders in ens utils 2019-02-25 15:03:46 -05:00
Michael Bradley, Jr 23ae78a6d6 refactor: be consistent with callbacks and promises
If a function receives a callback argument then it should not return a promise
if the caller's callback will be invoked. Both invoking a callback and
returning a promise can lead to at best confusion (in code review and at
runtime) and at worst non-deterministic behavior, such as race
conditions. Also, a caller supplying a callback may not handle a returned
promise, leading to unhandled rejection errors.

Refactor all readily identified functions where a callback argument can be
supplied but the function returns a promise regardless. Make use of
`callbackify` and `promisify` where it made sense to do so during the
refactoring. Some callsites of the revised functions may have been accidentally
overlooked and still need to be updated. Some functions that take callback
arguments may execute them synchronously, at odds with control flow of a
returned promise (if a callback wasn't supplied). Such cases should be
identified and fixed so that asynchronous behavior is fully consistent whether
the caller supplies a callback or receives a promise.

Make sure promises that pass control flow to a callback ignore rejections,
since those should be handled by the callback.

Don't return promise instances unnecessarily from async functions (since they
always return promises) and change some functions that return promises to async
functions (where it's simple to do so).

Whisper was using an ad hoc promise-like `messageEvents` object. However, that
object behaved more like an observable, since promises either resolve or
reject, and only do so one time. `messageEvents` was also intertwined with
callbacks. Replace `messageEvents` with RxJS Observable. `listenTo` now returns
Observable instances and callers can subscribe to them.

`Blockchain.connect` of embarkjs could suffer from a race condition where tasks
associated with `execWhenReady` might be ongoing when `connect`'s returned
promise resolves/rejects (or a caller supplied callback fires). Attempt to
ensure that returned-promise / supplied-callback control flow proceeds only
after `execWhenReady` tasks have finished. The control flow involved
is... rather involved, and it could use some further review and refactoring.

Bump webpack and the hard-source-plugin for webpack.

[util]: https://www.npmjs.com/package/util
2019-02-13 14:27:42 -05:00
Anthony Laibe 193abd4780 feat(ui): color console item info as success 2019-02-13 12:12:28 -05:00
Anthony Laibe cd326303ae feat(ui): keep state in frame 2019-02-12 16:42:16 -05:00
Michael Bradley, Jr 8091c4e6d0 build: cleanup .gitignore
Put common patterns we expect to use across most `packages/*` into the
top-level `.gitignore`. If there are package-specific patterns they can go in
that package's `.gitignore`. For example, `packages/embark-ui` ignores its
`build/` directory while commonly we ignore the packages' `dist/` directories.
2019-02-05 18:08:14 -06:00
Michael Bradley, Jr 2bf1b15ac3 build: cleanup .yarnrc
Yarn merges `.yarnrc` from the current working directory with `.yarnrc` files
higher in the directory tree, so that file isn't needed in each package.

Unfortunately, npm doesn't do the same for `.npmrc` files, so a similar cleanup
isn't possible.

Add version info to `test_app/extensions/embark-service/package.json` to that
`yarn install` can work correctly if manually invoked in `test_app`.
2019-02-05 14:15:39 -06:00
Michael Bradley, Jr 7a93e4b6a7 build: implement a monorepo with Lerna
TL;DR
=====

`yarn install` in a fresh clone of the repo.

`yarn reboot` when switching branches.

When pulling in these changes, there may be untracked files at the root in
all/some of:

```
.embark/
.nyc_output/
coverage/
dist/
embark-ui/
test_apps/
```

They can be safely deleted since those paths are no longer in use at the root.

Many of the scripts in the top-level `package.json` support Lerna's [filter
options]. For example:

`yarn build --scope embark` build only `packages/embark`.

`yarn build --ignore embark-ui` build everything except `packages/embark-ui`.

Scoping scripts will be more useful when there are more packages in the
monorepo and, for example, `yarn start` doesn't need to be invoked for all of
them while working on just a few of them simultaneously, e.g `embark` and
`embarkjs`.

It's also possible to `cd` into a particular package and run its scripts
directly:

```
cd packages/embark && yarn watch
```

Hot Topics & Questions
======================

What should be done about the [README][embark-readme] for `packages/embark`?
Should the top-level README be duplicated in that package?

Lerna is setup to use [Fixed/Locked mode][fixed-locked], and accordingly
`packages/embark-ui` is set to `4.0.0-beta.0`. The same will be true when
adding embarkjs, swarm-api, etc. to the monorepo. Is this acceptable or do we
want to use [Independent mode][independent]?

Scripts
=======

If a package doesn't have a matching script, `lerna run` skips it
automatically. For example, `packages/embark-ui` doesn't have a `typecheck`
script.

`yarn build`
------------

Runs babel, webpack, etc. according to a package's `build` script.

`yarn build:no-ui` is a shortcut for `yarn build --ignore embark-ui`.

`yarn ci`
---------

Runs a series of scripts relevant in a CI context according to a package's `ci`
script. For `packages/embark` that's `lint typecheck build test package`.

Also runs the `ci` script of the embedded `test_dapps` monorepo.

`yarn clean`
------------

Runs rimraf, etc. according to a package's `clean` script.

`yarn globalize`
----------------

Makes the development embark available on the global PATH, either via
symlink (Linux, macOS) or a shim script (Windows).

`yarn lint`
-----------

Runs eslint, etc. according to a package's `lint` script.

`yarn package`
--------------

Invokes `npm pack` according to a package's `package` script.

`yarn qa`
---------

Very similar to `ci`, runs a series of scripts according to a package's `qa`
script. The big difference between `ci` and `qa` is that at the top-level `qa`
first kicks off `reboot:full`.

There is a `preqa` script ([invoked automatically][npm-scripts]), which is a
bit of a wart. It makes sure that `embark reset` can be run successfully in
`packages/embark/templates/*` when the `reboot` script invokes the `reset`
script.

The `qa` script is invoked by `yarn release` before the latter proceeds to
invoke `lerna publish`.

`yarn reboot`
-------------

Invokes the `reset` script and then does `yarn install`.

The `reboot:full` variant invokes `reset:full` and then does `yarn install`.

`yarn release`
--------------

Works in concert with [lerna publish], which will prompt to verify the version
before proceeding. Use `n` to cancel instead of `ctrl-c` as `lerna publish` has
been seen to occasionally misbehave when not exited cleanly (e.g. creating a
tag when it shouldn't have).

```
yarn release [bump] [--options]
```

* `[bump]` see [`publish` positionals][pub-pos] and [`version`
  positionals][ver-pos]; an exact version can also be specified.
* `--preid` prerelease identifier, e.g. `beta`; when doing a prerelease bump
  will default to whatever identifier is currently in use.
* `--dist-tag` registry distribution tag, defaults to `latest`.
* `--message` commit message format, defaults to `chore(release): %v`.
* `--sign` indicates that the git commit and tag should be signed; not signed
  by default.
* `--release-branch` default is `master`; must match the current branch.
* `--git-remote` default is `origin`.
* `--registry` default is `https://registry.npmjs.org/` per the top-level
  [`lerna.json`][lerna-json].

To release `4.0.0-beta.1` as `embark@next` (assuming version is currently at
`4.0.0-beta.0`) could do:

```
yarn release prerelease --dist-tag next
```

For *test releases* (there is no longer a `--dry-run` option) [verdaccio] and a
filesystem git remote can be used.

Condensend instructions:

```
mkdir -p ~/temp/clones && cd ~/temp/clones
git clone git@github.com:embark-framework/embark.git
cd ~/repos/embark
git remote add FAKEembark ~/temp/clones/embark
```
in another terminal:
```
npm i -g verdaccio && verdaccio
```
in the first terminal:
```
yarn release --git-remote FAKEembark --registry http://localhost:4873/
```

`yarn reset`
------------

Invokes cleaning and resetting steps according to a package's `reset`
script. The big difference between `clean` and `reset` is that `reset` is
intended to delete a package's `node_modules`.

The `reset:full` variant deletes the monorepo's top-level `node_modules` at the
end. That shouldn't be necessary too often, e.g. in day-to-day work when
switching branches, which is why there is `reboot` / `reset` vs. `reboot:full`
/ `reset:full`.

Errors may be seen related to invocation of `embark reset` if embark is not
built, but `reset` will still complete successfully.

`yarn start`
------------

Runs babel, webpack, tsc, etc. (in parallel, in watch mode) according to a
package's `start` script.

`yarn test`
-----------

Run mocha, etc. according to a package's `test` script.

The `test:full` variant runs a series of scripts: `lint typecheck test
test_dapps`.

`yarn test_dapps`
-----------------

Runs the `test` script of the embedded `test_dapps` monorepo.

The `test_dapps:ci` and `test_dapps:qa` variants run the `ci` and `qa` scripts
of the embedded `test_dapps` monorepo, respectively.

`yarn typecheck`
----------------

Runs tsc, etc. according to a package's `typecheck` script.

Notes
=====

`npx` is used in some of the top-level and package scripts to ensure the
scripts can run even if `node_modules` is missing.

[`"nohoist"`][nohoist] specifies a couple of embark packages because
[`restrictPath`][restrictpath] is interfering with access to modules that are
located in a higher-up `node_modules`.

All dependencies in `packages/embark-ui` have been made `devDependencies` since
its production build is self-contained.

`packages/embark`'s existing CHANGELOG's formatting has been slightly adjusted
to match the formatting that Lerna will use going forward (entries in the log
haven't been modified).

Lerna will generate a CHANGELOG at the top-level and in each package. Since
we're transitioning to a monorepo, things may look a little wonky with respect
to old entries in `packages/embark/CHANGELOG.md` and going forward we need to
consider how scoping our commits corresponds to member-packages of the
monorepo.

In `packages/embark`, `test` invokes `scripts/test`, which starts a child
process wherein `process.env.DAPP_PATH` is a temporary path that has all of
`packages/embark/dist/test` copied into it, so that paths to test
helpers/fixtures don't need to be prefixed with `dist/test/` and so that a
`.embark` directory doesn't get written into `packages/embark`.

The `"engines"` specified in top-level and packages' `package.json` reflect a
node and npm pair that match (a source of confusion in the past). The pair was
chosen according to the first post v5 npm that's bundled with node. A
`"runtime"` key/object has been introduced in `packages/embark/package.json`
which is used as the basis for specifying the minimum version of node that can
be used to run embark, and that's what is checked by `bin/embark`.

Some changes have been introduced, e.g. in `lib/core/config` and
`lib/utils/solidity/remapImports` so that it's *not* implicitly assumed that
`process.env.DAPP_PATH` / `fs.dappPath()` are the same as
`process.cwd()`. There are probably several++ places where that assumption is
still in effect, and we should work to identify and correct them.

`embark reset` now deletes `embarkArtifacts/` within a dapp root, and
`embarkArtifacts/` is git-ignored.

`lib/core/env` adds all `node_modules` relative to `process.env.EMBARK_PATH` to
`NODE_PATH` so that embark's modules can be resolved as expected whether
embark's `node_modules` have been deduped or are installed in npm's flat
"global style".

`checkDependencies` has been inlined (see `lib/utils/checkDependencies`) and
slightly modified to support dependencies that have been hoisted into a
higher-up `node_modules`, e.g. as part of a yarn workspace. eslint has been
disabled for that script to avoid more involved changes to it.

`test_apps` is not in `packages/embark`; rather, there is `test_dapps` at the
top-level of the monorepo. `test_dapps` is an embedded monorepo, and its `ci` /
`qa` scripts `npm install` embark from freshly built tarballs of the packages
in the outer monorepo and then use that installation to run `embark test` in
the dapps. This should allow us to rapidly detect breakage related to
auto-bumps in transitive dependencies.

[filter options]: https://github.com/lerna/lerna/tree/master/core/filter-options
[embark-readme]: https://github.com/embark-framework/embark/blob/build/lerna/packages/embark/README.md
[fixed-locked]: https://github.com/lerna/lerna#fixedlocked-mode-default
[independent]: https://github.com/lerna/lerna#independent-mode
[npm-scripts]: https://docs.npmjs.com/misc/scripts
[lerna publish]: https://github.com/lerna/lerna/tree/master/commands/publish
[pub-pos]: https://github.com/lerna/lerna/tree/master/commands/publish#positionals
[ver-pos]: https://github.com/lerna/lerna/tree/master/commands/version#positionals
[lerna-json]: https://github.com/embark-framework/embark/blob/build/lerna/lerna.json#L11
[verdaccio]: https://www.npmjs.com/package/verdaccio
[nohoist]: https://github.com/embark-framework/embark/blob/build/lerna/package.json#L52-L55
[restrictpath]: https://github.com/embark-framework/embark/blob/build/lerna/packages/embark/src/lib/core/fs.js#L9
2019-02-04 14:28:49 -06:00