mirror of
https://github.com/embarklabs/embark.git
synced 2025-01-23 20:19:33 +00:00
b4478a9c46
This commit fixes the issue that it wasn't possible anymore to use named constructor arguments
in Smart Contract configurations.
For example, the following Smart Contract expects two constructor arguments:
```solidity
contract SomeContract {
constructor(address[] _addresses, int initialValue) public {}
}
```
The first being a list of addresses, the second one a number. This can be configured as:
```js
SomeContract: {
args: [
["$MyToken2", "$SimpleStorage"],
123
]
}
```
Notice how the order of arguments matters here. `_addresses` come first in the constructor,
so they have to be defined first in the configuration as well.
Another way to configure this is using named arguments, which is what's broken prior to this commit:
```js
SomeContract: {
args: {
initialValue: 123,
_addresses: ["$MyToken2", "$SimpleStorage"]
}
}
```
Using a notation like this ^ the order no longer matters as Embark will figure out the right
values for the constructor arguments by their names.
The reason this is broken is because there are several modules in Embark that register and
run a `deployment:contract:beforeDeploy` action, which are allowed to mutate this configuration
object. One of those modules is the `ens` module, which searches for ENS names in the arguments
and figure out whether it has to replace it with a resolved address.
One thing that particular module didn't take into account is that `args` could be either and
array, or an object and will always return an array, changing the shape of `args` in case it was
an object.
This is a problem because another module, `ethereum-blockchain-client`, another action is registered
that takes this mutated object in `determineArguments()` and ensure that, if `args` is actually an
object, the values are put in the correct position matching the constructor of the Smart Contract in
question.
One way to solve this was to use the newly introduced [priority](https://github.com/embark-framework/embark/pull/2031) and ensure
that `ens` action is executed after `ethereum-blockchain-client`'s.
However, the actual bug here is that the ENS module changes the shape of `args` in the first place,
so this commit ensures that it preserves it.
embark-ens
Implements ENS support in Embark
This module:
- registers console commands to interact with ENS
- deploys & setups ENS contracts depending on the network
- implements ENS support in EmbarkJS
- setups generated code acording to the config
API
command: ens:resolve - returns the address of an ens name
arguments:
name- ens name to resolve
response:
error- if an error occurs, null otherwiseaddress- address associated to the ensnamegiven
command: ens:isENSName - checks is it's a (valid) ENS name
arguments:
name- ens name to validate
response:
error- if an error occurs, null otherwiseresult- true/false depending ifnamegiven is a valid ens name
command: storage:ens:associate - associates an hash to an ENS domain
arguments:
optionsname- ens namestorageHash- hash to associate
response:
error- if an error occurs, null otherwise
Web API
endpoint: GET /embark-api/ens/resolve - returns the address of an ens name
arguments:
name- ens name to resolve
response:
{
address: <address of ens name>
}
endpoint: GET /embark-api/ens/lookup - returns the ens name of an address
arguments:
address- address to query
response:
{
name: <ens name of address>
}
endpoint: POST /embark-api/ens/register registers a domain or subdomain
arguments:
subdomain- ens domainaddress- address to associate
response:
{
name: <ens name>
address: <address>
}
Dependencies
- async
- eth-ens-namehash
- embarkjs.utils
- secureSend
- embark utils
- AddressUtils
- hashTo32ByteHexString
- recursiveMerge