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.
The embark-utils package, since 4.1.0-beta.1, is a transitive DApp dependency;
but it's loaded in the main process (not a child process), so embark-utils' own
deps can't be indirectly supplied from embark itself via NODE_PATH.
When introducing the `embark-api-client` in https://github.com/embark-framework/embark/commit/c1bbdbf34
we didn't properly update Cockpits apiService, resulting in calls to API endpoints
that don't exist.
This commit fixes a bug where calls to Embark's API to subscribe to whisper
channels are in a broken state.
It also updates Cockpit's apiService to no longer pass ignored parameters to embark-api-client.
With the move of Embark's modules into their own packages, the names under
which they are registered in the API service have changed as well.
This caused Cockpit to no longer being able to properly detect whether
ENS is enabled in the current Embark project
This package comes with a `setUpEnv()` function that can be called to
prepare Embark's environment variables for different process contexts.
This allows us to set up Embark's environment within a test runner context
without the requirement of importing `packages/embark/src/lib/core/env.js`,
which happens to set up those necessary environment variables as a side effect.
It's important that a path to `packages/embark`'s root is passed down to `setUpEnv()`
to ensure `EMBARK_PATH` gets the correct value.
E.g. within a package `embark-console`, `setUpEnv()` can be called within its tests
like the following:
```
// packages/embark-console/src/test/console.js
import { joinPath, setUpEnv } from 'embark-utils';
setUpEnv(joinPath(__dirname, '../../../embark'));
```
Here, `__dirname + '../../../embark'` ensures `EMBARK_PATH` points to the root
of `packages/embark`. This might look different in other contexts.
For example calling this function from a test file within `packages/embark`, this would
look like this:
```
// packages/embark/src/test/some_file.js
import { joinPath, setUpEnv } from 'embark-utils';
setUpEnv(joinPath(__dirname, '../../'));
```
As part of 880a3a6946, we've introduced a
regression where the `colors` package isn't imported in the scope anymore where it's
needed. In this case the pipeline package. This resulted in log output messages
such as:
```
undefinedwriting fileundefined
```
Adding the `colors` package as dependency and importing it accordingly
fixes the issue.
Make the adjustment even if the test script is currently disabled. Consistently
use nyc to generate coverage with mocha even if the test script is currently
disabled.
Pascal Precht
Jonathan Rainville
Robin Percy
Shailendra Shukla
Michael Bradley, Jr
André Medeiros
Ricardo Guilherme Schmidt
snyk-bot
Ricardo Guilherme Schmidt