Create React App automatically determines the base path for links within
production build artifacts based on the project's `"homepage"` field in
`package.json`.
An [alternative][alt-setting] is to set the `PUBLIC_URL` environment variable
in `.env.production`. Take that approach so embark-ui's `"homepage"` can
continue to point to its home in the monorepo on GitHub.
Generate source maps in the production build of embark-ui. Doing so increases
the size of the package's tarball by a few MB (it was already large because of
the editor component), but the benefits of being able to much more easily debug
a production build (e.g. when interacting with users experiencing problems)
outweigh the size cost.
[alt-setting]: https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/config/paths.js#L36
`"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
When testing production installs of embark 4.0.0-beta.1 (local registry), the
`restrictPath` mechanism of `core/fs` was too restrictive, interfering with
template generation (cause not completely determined). Also, it's known that
`restrictPath` causes problems when resolving plugins, etc. from "higher up"
`node_modules` paths, e.g. in the monorepo.
Introduce `codeRunner/fs` which uses `restrictPath` as before, and in `core/fs`
remove `restrictPath`. Revise the other `codeRunner` modules to use
`codeRunner/fs`.
Don't implicitly rely on explorer overview having been loaded to initially
populate `entities.transactions`. Also, that container should watch for new
blocks/transactions same as the other explorer containers.
Restore `fetchTransactions` and related to TransactionsContainer. It's no
longer the basis of pagination (it didn't work as desired), but when navigating
through the transaction pages that action will ensure more transactions are
fetched so that the account page will list more of an account's transactions
over time. That was a side effect of `getTransactions` before it was removed in
favor of `getBlocksFull`, which is still the basis of revised pagination logic
in the transactions explorer.
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.
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.
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.
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.
Previously, storage providers in embarkjs were not waiting for their respective storage process (ipfs and swarm) to start before running `registerProvider` and `setProvider` in the console.
This PR forces the `registerProvider` and `setProviders` from running in the console until the storage processes have loaded. As a side effect, the code generation of `EmbarkJS` must wait for the storage module ot be fully initiated (ie once the processes have launched and the `registerProvider` and `setProviders` have been run) before generating the code.
This fixes errors pertaining to `Could not connect to a storage provider using any of the dappConnections in the storage config` as these errors were typically caused by `setProviders` being called before the storage processes had fully launched.
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.
Prevent embark from crashing when app assets are not specified in `embark.json`.
Previously, if the `app` property of `embark.json` was missing, embark would crash with the error `TypeError: Cannot convert undefined or null to object`.
With this PR, the missing property is null-checked.
Add an `enabled` property to the pipeline config. This lets developers disable the pipeline using the config file.
Updates to the enabled property will be reflected while embark is running. For example if embark is running with the pipeline, setting `enabled: false` in the pipeline config will build/deploy the contracts but not run the pipeline. Conversely, if embark is running with the pipeline disabled, enabling the pipeline in the config will build/deploy the contracts then build the dapp.
`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
https://github.com/embark-framework/embark/pull/1367 introduced a change that prevented the `blockchain_listener` from listening to logs until the IPC server connected. However, the restriction went too far, and included restricting registration of console commands and API endpoints for the regular transactions feature.
This fix reverts the changes that affect registration of regular txs endpoints and console commands.
It's possible to pass a `--require` option to mocha to load a script that sets
up `process.env.DAPP_PATH` as needed for embark's tests; that approach is
preferable to running mocha in a child process because when running in a child
process there seemed to be problems with sources maps and with VS Code's
debugger.
After the changes in this PR, the following works as expected, i.e. when there
are runtime errors line/col numbers are reported per the files in `src/`:
```
$ yarn build:no-ui
$ cd packages/embark
$ npx mocha "dist/test/**/*.js" \
--exit \
--no-timeouts \
--require ./scripts/test.js \
--require source-map-support/register
```
And the following VS Code launch config works well for me:
```json
{
"type": "node",
"request": "launch",
"name": "test - packages/embark",
"cwd": "${workspaceFolder}/packages/embark",
"program": "${workspaceFolder}/node_modules/mocha/bin/_mocha",
"args": [
"'dist/test/**/*.js'",
"--exit",
"--no-timeouts",
"--require",
"./scripts/test.js",
"--require",
"source-map-support/register"
],
"autoAttachChildProcesses": true,
"sourceMaps": true
}
```
NOTE for VS Code users: I found it's important to specify
`"'dist/test/**/*.js'"` in the launch config instead of
`"\"dist/test/**/*.js\""`, and that it's important to specify `"program":
"${workspaceFolder}/node_modules/mocha/bin/_mocha"` vs. `"program":
"${workspaceFolder}/packages/embark/node_modules/.bin/mocha"`.
KNOWN ISSUES: when there are runtime errors during `yarn test` in
`packages/embark`, line/col numbers reflect the sources in
`package/embark/dist` because `nyc` isn't setup correctly to use the
source-maps generated by babel. A solution has not yet been found.
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.
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.
Michael Bradley, Jr
Jonathan Rainville
Andre Medeiros
Iuri Matias
emizzle
Pascal Precht