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.
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.
`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()`.
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`.
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.
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.
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
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.
The webserver's job is to serve files generated by Embark's built-in pipeline,
however, since v4 users can choose they front-end tool to take care of building,
bundling and packing their DApps. Usually these tools come with a built-in
dev server as well.
Therefore, when the pipeline is turned off (which also soon will be the default),
there's not need start a webserver.
In https://github.com/embark-framework/embark/pull/1119 we've introduced a feature where
users can provide an already compiled ABI for Smart Contracts so they can be used
without the need to compiling them again.
This also means that, internally, those Smart Contract object won't have any
bytecode attached to it.
Later on, in 387d33a076, we've introduced a warning
which is rendered when a Smart Contract's bytecode is too large. The check expects
a Smart Contract object to have bytecode associated to it, which will break the code
in cases where a Smart Contract has already an ABI and therefore didn't need compilation.
This commit ensures we only check a Smart Contract's bytecode when bytecode exists for
the Smart Contract in question.
The previous link was pointing to readthedocs.io, which wasn't active. So here I've replaced it with the link to the official documentation on the Embark website.
When trying to either sending, or listening to whisper channels within
Embark's consoles (CLI and Cockpit), the console outputs an error that
`EmbarkJS` isn't defined.
E.g. running:
```
> EmbarkJS.Messages.listenTo({ topic: ['somechannel'])
```
Outputs:
```
EmbarkJS is not defined
```
This seemed very odd as outputting `EmbarkJS` and all of its members
worked totally fine.
It turns out that both methods, `listenTo()` and `sendMessage()`, in
`EmbarkJS.Messages` are not necessarily what one thinks they are.
EmbarkJS decorates both methods to create some options that need to be
available in the delegate, two of them being `EmbarkJS.Utils.toAscii`
and `EmbarkJS.Utils.fromAscii` (ac76a40a61/packages/embarkjs-whisper/src/index.js (L43-L62) and ac76a40a61/packages/embarkjs-whisper/src/index.js (L64-L73))
These two global references to `EmbarkJS` are the only ones in `embarkjs-whisper`
and they are not the same reference as the `EmbarkJS` sandbox global
registered in the VM here ac76a40a61/packages/embark-code-runner/src/index.ts (L33).
In other words, the `EmbarkJS is not defined` message actually refers
to the `EmbarkJS` in the wrapping method, not the one registered with
the VM, which is also why inspecting the `EmbarkJS` object through the
VM works fine.
Since the `toAscii()` and `fromAscii()` methods in use are really just
facades around `web3.utils.[fromAscii|toAscii]()`, we can replace the
global EmbarkJS dependency with web3 utils that are already available
anyways.
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.
When running unit tests inside a project that configures ENS subdomains using Smart Contract directives,
the tests will output an error because of that particular Smart Contract's `deployedAddress` being `undefined`.
This happens only when running tests, not when deploying the Smart Contracts including the custom ENS setup.
It turns out that Embark attempts to compile and deploy the Smart Contracts of the project *twice* - once
before tests are executed, and another time **after** tests are done executing.
Both compilations/deployments are triggered through our custom `config()` function within test context,
which ensures all Smart Contracts are deployed before tests are executed.
This explains a few things:
1. There's no such issue when running `embark run`, in fact the custom ENS subdomains work perfectly fine
2. That's also why the tests are passing fine as well as the first compilation/deployment doesn't have any issues.
The errors only appear *after* the tests have been executed.
Still, this raises a few more questions, mainly
- Why is the Smart Contract's `deployedAddress` property `undefined` when `config()` is executed a second time?
- Why is `config()` executed a second time in the first place?
Let's look into both of these.
Assuming that there's a valid reason that `config()` is called twice, it's remains unclear why that property
of a Smart Contract object is `undefined` in the second run. The reason for that is that Embark determines whether
or not a particular Smart Contract should be deployed. One of the routines ensures that only the Smart Contracts
configured for deployment are actually attempted to be deployed (as opposed to just deploying all Smart Contracts
found in the file system).
It turns out that the second `config()` call is done without any Smart Contract configuration, resulting basically in no deployment
for any Smart Contract of the application. The `address` and `deployedAddress` of a Smart Contract object are however only set
*after* deployment, resulting in them being `undefined`.
**All this makes sense.**
`config()` is simply not designed for being used with an empty `contracts: {}` config. This raises another question:
Why is `config()` called with an empty configuration? This leads us to the second point.
It does seem a bit weird that Embark tries to configure compile *and* deploy a DApp's Smart Contracts again right **after**
the tests have been executed. So why is that?
A quick `git blame` (no blame intended here) shows us that this routine has been introduced in https://github.com/embark-framework/embark/commit/12cbb7bdd.
Notice the second list point of the commit:
> Contracts that had been compiled in the JS tests were being deleted at the end of the JS test run, which caused errors
> with the files not being found. The fix was to reset the contracts config to no longer require the non-test contracts
> to be compiled/deployed.
The above is a little tricky to understand without a little bit of context: Embark runs two types of tests, JavaScript tests
and Solidity tests. It does that as part of a single process, keeping state in memory in-between those two test runs.
With that in mind, the commit mentioned above says the following:
1. Artifacts that Embark generates as part of its compilation process are erased after JS tests are done executing.
This makes a lot of sense as we don't want to leave any side effects undone when tests are finished.
2. The commit ensures that not only the artifacts are removed from disc, but also updates Embark's state in memory
for `contractFiles`. The reason for that is that otherwise, in the second test run for Solidity tests, Embark will
throw errors as it tries to look up the path for the artifacts in memory for all the Smart Contracts that had been
compiled before.
3. Last but not least, there's *another* state that needs a reset and that's the Smart Contract configuration. If Embark
doesn't reset the memory it'll assume in the second run that all of those Smart Contracts left in memory
"have no code associated to it", while in reality, they shouldn't be in memory in the first place.
So it seems that `config()` is called a second time with an empty Smart Contracts configuration just to ensure that memory
is reset and no error messages are shown.
As discussed earlier, this unfortunately also introduced a lot of side effects along the way as Embark tries to reregister
ENS subdomains from Smart Contracts that are marked as undeployed and therefore don't have an address to interpolate.
While there's probably different ways to go about it, the most straight forward fix is to simply not call `config()`
a second time when it's really not needed. If the goal is to just reset the memory, we can take advantage of
Embark's internal `config:contractsConfig:set` event, which is what this commit is doing.
Michael Bradley, Jr
Pascal Precht
Jonathan Rainville
Iuri Matias
emizzle
Robin Percy
Shailendra Shukla
André Medeiros
Ricardo Guilherme Schmidt
snyk-bot