Turns out that, when Embark tries to replace ENS subdomains, it would fail
if `subdomains` aren't defined in the namesystem configuration.
This commit adds a safeguard so that not defining `subdomains` is fine.
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.
When making use of the `useBuiltIns: 'usage'` option for @babel/preset-env
(which is the case for all transpiled packages in Embark's monorepo) a package
needs to have both @babel/runtime-corejs3 and core-js@3 specified as
dependencies.
BREAKING CHANGE:
node: >=10.17.0 <12.0.0
npm: >=6.11.3
yarn: >=1.19.1
node v10.17.0 is the latest in the 10.x series and is still in the Active LTS
lifecycle. Embark is still not compatible with node's 12.x and 13.x
series (because of some dependencies), otherwise it would probably make sense
to bump our minimum supported node version all the way to the most recent 12.x
release.
npm v6.11.3 is the version that's bundled with node v10.17.0.
yarn v1.19.1 is the most recent version as of the time node v10.17.0 was
released.
* chore(@embark/): move embarkjs packages to their own folder
* chore(@embark/): rename embark-ui folder to cockpit
* chore(@embark/): rename packages already in logical folders to remove embark- prefix
chore(@embark/): rename packages already in logical folders to remove embark- prefix
update package.json files to use correct eslint config
remove core/* from package.json workspaces
Pascal Precht
Jonathan Rainville
Michael Bradley, Jr
dependabot-preview[bot]
Iuri Matias