Commit Graph

9 Commits

Author SHA1 Message Date
Pascal Precht a4a0e9dc33 feat(plugins/specialconfigs): adds support for Smart Contract args as functions
This commit introduces a new feature that enables users to calculate Smart Contract
constructor arguments lazily using an (async) function. Similar to normal Smart Contract
configurations, the return or resolved value from that function has to be either a list
of arguments in the order as they are needed for the constructor, or as an object with
named members that match the arguments individually.

```
...
development: {
  deploy: {
    SimpleStorage: {
      args: async ({ contracts, web3, logger}) => {
        // do something with `contracts` and `web3` to determine
        // arguments
        let someValue = await ...;
        return [someValue];

        // or
        return {
          initialValue: someValue
        };
      }
    }
  }
}
...
```

Closes #2270
2020-03-03 10:14:58 +01:00
Pascal Precht 73d04433cf feat(@embark/deployment): introduce `interfaces` and `libraries` configuration
This commit adds two new configuration settings for Smart Contract configuration:

- `interfaces` - Any Smart Contract that represent an interface or is used for inheritance
- `libraries` - Any Smart Contract that is used as a library

This makes the configuration less redundant in cases where otherwise the `deploy`
property has been set to `false`, such as:

```
deploy: {
  Ownable: {
    deploy: false
  },
  ...
}
```

The above can now be done via:

```
interfaces: ['Ownable'],
deploy: {
  ...
}
```
2020-01-15 09:45:42 -05:00
Iuri Matias af51e2d793 bugfix (@embark/stack/embarkjs): set default gas so it's an optional parameter for onDeploy directives in the contracts config 2019-11-12 17:08:48 -05:00
Pascal Precht b4478a9c46 fix(@embark/ens): don't change shape of Smart Contract args in action hooks
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.
2019-11-11 14:01:48 -05:00
Pascal Precht 92f6dd4ce9 fix(@embark/dapps): add missing Smart Contract configurations
Those had been removed in a refactor while the Smart Contract sources have been
kept around, resulting in deployment errors as Embark doesn't know what to do
with the Smart Contracts that don't come with a dedicated config.

This commit re-adds the configurations to make the deployment pass again.
2019-11-06 13:16:44 +01:00
Jonathan Rainville 9e654c533e fix: fix ws providers to have the patch for a bigger threshold (#2017)
* fix: fix ws providers to have the patch for a bigger threshold

* chore (@embark/dapps): add big contract to test WS issue with large contracts
2019-10-30 16:02:17 -04:00
Jonathan Rainville 2193d82399 fix(test-app): make test app test all pass (#1980)
Fix a lot of bugs and reenable a couple of modules
Some tests were kept disabled, mostly the ENS and EmbarkJS tests
Those need to add back a fairly significant feature to work
Add back missing solidity contracts
2019-10-22 09:27:22 -04:00
Michael Bradley b736ebefcd refactor: initial steps toward 5.0.0-alpha.0 (#1856)
BREAKING CHANGE:

There are more than several breaking changes, including DApp configuration for
accounts.
2019-08-30 16:50:20 -04:00
Michael Bradley, Jr de0f02d00a build: make DApp templates member packages of the monorepo
Previously, templates were in a subdirectory of `packages/embark`. Reorganize
them so that they are member packages of the monorepo. This allows them to
cleanly depend on other members of the monorepo,
e.g. `embarkjs-connector-web3`.

It is desirable for the templates, in the context of the monorepo, to specify
embark as a dependency, to take advantage of `npx embark test` (and it's a
"forward looking" setup re: how we plan to evolve embark). However, if embark
were to specify the template packages as dependencies a circular relationship
would be introduced, which is [unsupported by Lerna][circular]. Therefore,
revise the template generator so that all templates are resolved / fetched at
runtime, i.e. `boilerplate`, `demo`, and `simple` are no longer
"built-ins" *per se*. This change won't be apparent to embark's users, but it
does mean that the template generator won't work (in a production install of
embark) if it can't connect to the npm registry, i.e. when the user runs
`embark demo` or `embark new [--simple]`. When embark is inside the monorepo,
templates are resolved and copied from the yarn workspace rather than being
fetched from the registry, which is convenient for development. Also, any
template dependencies that are members of the monorepo are linked into the
copied template's `node_modules` rather than being installed from the registry,
again for convenience. During template generation, remove scripts and
dependencies that pertain only to membership in the monorepo; for now, that
involves removing embark as a dependency since we're not quite ready for that
arrangement to be the default, i.e. outside of the monorepo.

Refactor the root scripts so that more of them can consistently be used with
Lerna's filter options, e.g. `--scope` and `--ignore`. "Combo" scripts that
don't support filtering generally have a `:full` postfix.

Flip `clean` and `reset` scripts at the root and in the member packages for
consistency re: Lerna's notion of `clean` and embark's notion of `reset`. Have
each package run its `reset` script when its `clean` script is invoked (and
that's all for now), relying on `lerna clean` to delete packages'
`node_modules` in view of how Lerna's topological sorting works.

Lift the implementation of `embark reset` into a private package in
`packages/embark-reset` and make it a bundled dependency of embark. Packages in
`dapps/*` depend on `embark-reset` directly and make use of it with `npx
embark-reset` (but only in monorepo context). This removes a "wart" where
reboots could show errors when embark's sources aren't already built in
`packages/embark/dist`. Users will not notice any difference since `embark
reset` works as before, transparently making use of the `embark-reset`
package. The only downside to having it be a bundled dependency of embark is
that bundled deps have all of their `node_modules` included in the tarball
built with `npm pack` (that's why having the templates as bundled dependencies
of embark isn't a viable approach). However, `embark-reset` only has one
dependency, `rimraf`, which is a tiny module, so the cost seems acceptable.

As part of the reorganization, move `test_dapps` into `dapps/tests` and
`packages/embark/templates` into `dapps/templates`. Keep the directory names
short but revise the package names to facilitate simple filtering with
`embark-dapp-*`. Consolidate `.yarnrc` and `.gitignore` and clean up some
redundant ignore listings.

Scripts run with `--scope embark-dapp-*` use `--concurrency=1` to avoid
conflicts that could arise over network ports. The `ci:full` and `qa:full`
scripts use `--concurrency=1` in all scopes, for two reasons: resource
limitations on Travis and AppVeyor result in slower runs with concurrency >1,
and if something fails in those contexts it's easier to see what went wrong
when Lerna's output isn't interleaved from a bunch of scripts in `packages/*`.

Bump the Lerna version.

[circular]: https://github.com/lerna/lerna/issues/1198#issuecomment-442278902
2019-03-05 10:20:57 -06:00