`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.
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.
Previous to this PR, `web3` was only made available to each test case, as it was put in to the global namespace after each test deploy. This was causing issues for tests that use `web3` in the test description (ie in `describe()` or `contract()` functions), as the deploy had not happened yet, and thus `web3` was not yet available. The error encountered in these cases was `web3 is not defined`.
This PR puts `web3` in the global namespace before setting up the tests, making it available to test descriptions.
Allow `embark upload` to upload to IPFS/Swarm even if the storage module is disabled in the storage config.
An easy way to test this is to set `config/storage.js` > `enabled` to `false` in the demo. Then run `embark upload`.
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.
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.
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
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.
**Cache suggestions**
Suggestions are cached for better performance on each request. When contracts are deployed, the suggestion cache is cleared, allowing for updated contract methods to be built in to the suggestions.
** Handle edge cases **
Handle cases when console command is parsed as an empty string, or possibly returns an empty object, which would cause `Object.getOwnPropertyNames` to throw an error (that is ultimately swallowed).
Swarm was not being registered as a service due to a recent change that introduced a bug. The previous change was meant to register “swarm” as a console command to provide output for the `swarm` console command when swarm had not been registered in the VM. The bug, however, returned too early in the cases when swarm was meant to be enabled, thus effectively not registering the entire process.
The fix simply returns only when swarm is in fact, disabled, and also alters slightly the way swarm is determined to be enabled (the changes of which have been copied over to `ipfs`).
Add the ability to pass an error in the callback of an event action.
Currently, event actions could either pass back a an error OR a result, but not both, and with no way to distinguish between the two parameters. This PR adds the ability to pass an error as the first parameter of the action callback.
An example of a use case that this fixed: errors on `deployIf` were silently swallowed, which has now been fixed.
All instances of `events.request(“deploy:contracts”)` were given an `error` parameter in their callback, and errors printed if it is not undefined.
All instances of `registerActionForEvent` were combed to ensure any callbacks were passing the expected error and result.
`web3.eth.getAccounts` was returning an empty array in the console due to a change, that I’m unsure of what the original intention was for.
@andremederios, could you please take a look, and let me know if this breaks the intention of the original changes?
Cockpit whisper messages were not being subscribed to due to a inocuous bug that would swallow errors and ultimately not be subscribed to the `rxjs` observer.
Michael Bradley, Jr
Andre Medeiros
Jonathan Rainville
emizzle