Commit Graph

5571 Commits

Author SHA1 Message Date
Jonathan Rainville 9dcf236ab7 feat(@embark/site): update blockchain and contracts docs to v5 2019-07-12 12:52:06 -04:00
Jonathan Rainville 162d66b675 feat: enable starting and switching storage configs in tests 2019-07-12 12:51:56 -04:00
Jonathan Rainville 63ab21ee81 feat(@embark/test-runner): make modules configurable per test
Make storage, ens and communication configurable per test
Tested ENS and it works like a charm
2019-07-12 12:44:53 -04:00
Jonathan Rainville 9648aaf4b1 feat: add test env to embark test and disable modules by default 2019-07-12 12:40:34 -04:00
Jonathan Rainville 8a2325c071 feat: add warning and errors for new configs 2019-07-12 12:40:33 -04:00
Jonathan Rainville 92d25e1d1b refactor: simplify blockchain and contract configs
Implements https://notes.status.im/yrfs8w87SZKfE2ft6MoFIg#
2019-07-12 12:40:27 -04:00
Michael Bradley, Jr 5930cce7dd chore(release): 4.1.0-beta.5 2019-07-10 16:21:47 -05:00
Michael Bradley, Jr 72baf5f6dd refactor(@embark/api-client): remove console.dir statements used during development 2019-07-10 16:06:27 -05:00
Michael Bradley, Jr 5828ae6cc5 fix(@embark/storage): revise timing for process:started and code eval to avoid race conditions 2019-07-10 16:06:27 -05:00
Pascal Precht 2531fc1d26 fix(@embark/test-runner): make `--tx-details` option work again
In https://github.com/embark-framework/embark/commit/87d92b6091 we've introduced a feature in our test runner
to report exact gas costs used when calling Smart Contract methods that
cause computation.

Embark keeps a list of deployed contracts in memory and for all transactions
happening during tests, it'll match them to the contracts that performed them
to produce the report logs.

Unfortunately, we've been [resetting that memory](https://github.com/embark-framework/embark/commit/87d92b6091#diff-92b4f79a0473160fe700440b1ced5204R140) of deployed contracts
after every test, making it practically impossible for Embark to find
matching contracts for any transactions, because contracts aren't necessarily
redeployed per spec, resulting in no additional transaction logs whatsoever.

This commit ensures that the memory is never erased and at the same time
ensures it's not leaking infinitely in case multiple contracts are
deployed multiple times in the same process over several specs.
2019-07-10 14:20:26 -05:00
Michael Bradley, Jr 3590197c55 fix(@cockpit/debugger): check if `debuggingContract` is undefined
Guard against redux-saga fetching races in `componentDidUpdate`.
2019-07-09 13:02:51 -05:00
Pascal Precht 3f77272e71 fix(@cockpit): don't send invalid value to Smart Contract methods
We've introduced a regression in 536a4029ba where the default
`value` sent to payable Smart Contract methods is `-1`, resulting in errors as it's not
a valid value.
2019-07-09 08:10:13 +02:00
Jonathan Rainville 9390673ef4 chore: update shelljs to 0.8.3 for all packages 2019-07-08 11:25:30 -05:00
Jonathan Rainville 1e59b58887 feat(@embark/solc): add embark-solc to monorepo 2019-07-08 11:25:30 -05:00
Jonathan Rainville ad796bc8f8 fix(@embark/site): update contractGeneration plugin api 2019-07-08 10:26:16 -05:00
Jonathan Rainville c87d7da4cc fix(@embark/code-generator): use plugins for contract generation
`contractGeneration` plugins were only used in the Embark console
Now they are used to generate the Dapp artifacts too
2019-07-08 10:26:16 -05:00
emizzle 536a4029ba feat(@cockpit): Pass tx value as wei and add validation
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
2019-07-08 10:00:34 -05:00
Pascal Precht 70ff3c1825 fix(@embark/contracts-manager): ensure ETH values sent through APIs are converted to string
This is due to a bug that has been introduced in d10c0b7951 where we end up
sending values as numbers to web3's `toWei()` utility. The `value` is always sent as number
and in fact always defined, so we just need to check for it's type and convert it to a string
according to `toWei()`'s API.
2019-07-08 10:00:34 -05:00
Michael Bradley, Jr bd602b45ee refactor(@embark/storage): wrap require.resolve in try/catch
Wrap `require.resolve` in try/catch instead of testing the path with
`embark.fs.access`.
2019-07-05 17:01:09 -05:00
Michael Bradley, Jr 13e926659f refactor(@embark/core): move CoreProcess into embark-core 2019-07-05 16:07:58 -05:00
Michael Bradley, Jr 04694edb0b refactor: move storage, ipfs and swarm modules into their own packages 2019-07-05 16:07:45 -05:00
Michael Bradley, Jr 158de04baf refactor(@embark/ens): remove caret range from async dependency 2019-07-05 16:05:21 -05:00
Pascal Precht d76a82a30a fix(@embark/deployment): don't over estimate gas when running tests against non-simulator nodes
When running tests against non-simulated blockchain nodes, even for simplex
Smart Contracts, deployment transactions would exceed the block gas limit.

E.g. running `embark blockchain` in one process and `embark test --node embark`
in another, inside our demo application, will throw an error when Embark attempts
to deploy its `SimpleStorage`:

```
Compiling contracts
Compilation done

[SimpleStorage]: error deploying =SimpleStorage= due to error: Returned error: exceeds block gas limit
Error deploying contracts. Please fix errors to continue.
Error deploying contracts. Please fix errors to continue.
terminating due to error
Error deploying contracts. Please fix errors to continue.
```

The reason for that is because in https://github.com/embark-framework/embark/pull/1650, we've introduced a static
gas estimation for Smart Contract deployment that is just right below Ganache's
maximum gas limit of `6721975`, since Ganache tends to underestimate gas for
complex Smart Contracts due to its [low base fee](8ad1ab29de/lib/utils/gasEstimation.js (L33-L39)).

The static gas estimation would apply any time we're in a test context, but we
didn't take into account the case where tests are executed against nodes
other than the simulated environment.

As mentioned in the comments in the linked PR:

> If this is not spec'ed at all, I wonder what complications it could cause when
> at some point we maybe switch to not using Ganache anymore for tests, or even
> the user itself (which I think is a reasonable thing to do).

This causes the error described above because we easily reach the block gas limit
with just two Smart Contracts and Embark already deploys a few Smart Contracts for
ENS.

So basically what we want is to use the static gas estimation when we know
the node we're connecting to is Ganache. In all other cases we can rely on the
standardized gas estimation offered by the node.
2019-07-05 14:15:12 +02:00
Jonathan Rainville 421c340613 fix(@embark/ipc): fix functions not being printed in console 2019-07-05 14:12:43 +02:00
Jonathan Rainville 0e9a4a136b feat(@embark/ui): sort contracts and functions alphabetically 2019-07-05 14:11:34 +02:00
Michael Bradley, Jr 52d54f0d87 fix(@cockpit/explorers): consistently display "Mined on" timestamps
Adjust the API endpoints to augment transaction objects with a timestamp
property from their corresponding blocks. This removes the necessity to copy
the timestamp property from a block to its transactions in the client.

Introduce a `formatTimestampForDisplay` util function in Cockpit for
consistently transforming timestamps into relative or absolute dates, depending
on whether a date is sometime during the last day.
2019-07-03 08:25:08 -05:00
Michael Bradley, Jr 7d27125eed fix(@embark/code-runner): restore EmbarkJS.environment property in the cli dashboard
The property is set/available on EmbarkJS in the artifacts, i.e. in a browser
build; but sometime since v3.2.4 it was no longer availble in the cli dashboard
environment.
2019-07-02 10:48:53 -05:00
Pascal Precht 93ca3ad97c fix(@embark/embarkjs-whisper): Messages.isAvailable() should always return a promise
`EmbarkJS.Messages.isAvailable()` in some cases return synchronously (when whisper isn't
set up), in other cases asynchronously. This actually breaks our demo application for
the following reason:

We check for Whisper's availability via:

```
EmbarkJS.Messages.Providers.whisper.getWhisperVersion((err, _version) => {
  if (err) {
    return console.log(err);
  }
  this.setState({whisperEnabled: true});
});
```

There's a couple of problems here:

- This code will break right away when whisper isn't available, resulting in an error:
  ```
  Cannot read property _requestManager of undefined
  ```

- The reason this error happens is because there's no `web3` object available inside
  our EmbarkJS.Messages code. Even though there **is** a web3 object, EmbarkJS.Messages
  doesn't know about this because it only sets it when its `setProvider()` API is called,
  which effectively doesn't happen at all when Whisper isn't enabled on the connected
  node

- While this could be fixed with a simple check on whether EmbarkJS.Messages' internal
  `web3` references is a thing, really what should be used in the demo is the `isAvailable()`
  API.

`isAvailable()` should always return a promise (similar to `EmbarkJS.Storage.isAvailable()`.

This commit ensures that `isAvailable()` always returns a promise and changes the demo
template to use `isAvailable()` over `getWhisperVersion()`.
2019-07-01 11:11:03 +02:00
Pascal Precht fc7eb0cca6 uiux(@cockpit/sign-and-verify): improve wording for verifying messages 2019-07-01 11:10:37 +02:00
Michael Bradley, Jr eecb48f5b6 chore(release): 4.1.0-beta.4 2019-06-27 14:23:32 -05:00
Jonathan Rainville f6d7a54195 fix(@embark/deploy-tracker): fix getting the block 0 with sim --fork 2019-06-27 14:12:29 -05:00
Pascal Precht 1b6987ee8f fix(@dapps/templates/demo): ensure whisper channel state is set correctly 2019-06-27 14:11:24 -05:00
Jonathan Rainville 198a5dc3f4 fix(@embark/solidity): show a better error message in debug 2019-06-27 14:10:53 -05:00
Michael Bradley, Jr 7652e1d75c refactor(@embark/site): remove embarkjs-connector-web3 instructions
Also include a note on the "How to upgrade to Embark 4" blog post from March
2019.
2019-06-27 14:10:12 -05:00
Iuri Matias fc4faa8ba9 fix: alleviate races re: embarkjs by introducing Plugin#addGeneratedCode and related refactors 2019-06-27 14:10:12 -05:00
Michael Bradley, Jr d684b9af0f refactor(@embarkjs/web3): make web3 connector an internal plugin like the other embarkjs-* packages
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`.
2019-06-27 14:10:12 -05:00
emizzle 71cb161525 feat(@embark/blockchain-connector): Add command to get full account info
This PR adds a command to get full account details from the contradts config that includes info like private key.

The existing, and similar command, `blockchain:provider:contract:accounts:get` would only return account addresses if they existed, and not the full account info.
2019-06-27 08:42:58 -05:00
Michael Bradley, Jr 2ce9ca6bb0 fix(@embark/coverage): function types and single statement ifs 2019-06-27 08:40:24 -05:00
Pascal Precht 610d8f1baa fix(@cockpit/utils): Ensure whisper channels are at least 4 characters long
This check was already made when sending messages to whisper channel, however, we didn't
perform the same check when subscribing to channels within cockpit.
2019-06-27 08:36:25 -05:00
Pascal Precht 322397f81c fix(@dapps/demo): don't allow subscription to whisper channels with less than 4 chars
This has been a problem in Cockpit as well and was fixed accordingly.
Whisper doesn't allow subscribing to channels with names that have less
than 4 characters.

This could be fixed in different ways, one being on the library level
(e.g. have embark check for the given length and not subscribing when it
doesn't pass the check), the other one being on the application/ui level.

The reason it makes sense to solve this in the application layers is because
we keep the it open for users of EmbarkJS.Messages APIs to handle errors
the way they want.

Fixes #1666
2019-06-27 08:36:05 -05:00
Jonathan Rainville 0a388d741e chore(@embark/site): remove connect() doc and add back onReady 2019-06-26 11:55:26 +02:00
Jonathan Rainville 908aa3b148 fix(templates): fix templates because tests don't like empty files 2019-06-21 11:00:27 -04:00
Jonathan Rainville 9646673c6f fix(@embark/test-runner): only run tests on files with describe 2019-06-21 11:00:27 -04:00
Jonathan Rainville 5044403a03 feat(@embark/site): add section on getting account from describe 2019-06-21 11:00:27 -04:00
Jonathan Rainville 332229ff9d feat(@embark/test-runner): return accounts in the describe callback 2019-06-21 11:00:27 -04:00
Jonathan Rainville 8c16541019 feat(@embark/test-runner): wait for deploy before enterning describe 2019-06-21 11:00:27 -04:00
Pascal Precht ae5b92ff45 chore(docs): remove encoded special chars for paginator buttons 2019-06-21 10:51:14 -04:00
Pascal Precht ebe61f4085 fix(docs): ensure paginator helper has `__()` local
Templates used for rendering data inside helpers need to all over their local variables
passed down so they can be evaluated against some context object.

We didn't pass down the i18n `__()` function to the paginator template of our custom
theme resulting in compilation errors during site generation.

This commit fixes it.
2019-06-21 10:51:14 -04:00
Pascal Precht 9f1c4cb329 docs: fix Messages.listenTo() API docs 2019-06-20 15:30:44 +02:00
Robin Percy f81e25710f 1 grammatical change hangover from other PR. 2019-06-20 09:04:58 -04:00