We've introduced a regression in 2dfaaa8201 where zero addresses
have been replaced with a constant, including the ones within ENSFunctions.
The problem is that this code is as well added to the EmbarkJS client, where importing
`../../utils/addressUtils` won't work as it isn't available.
This commit reverts back to have ENSFunctions having its own ZERO_ADDRESS constant.
This commit fixes a bug in a scenario where dapp developers choose to refer
to an already deployed Smart Contract (they don't own) and want to use its web3 instance
on the client-side, or in deployment hooks.
For example, Dapp developers might want to do something like this:
```
// config/contract.js
...
contracts: {
SimpleStorage: {
address: '0x1234...' // SimpleStorage is already deployed
}
},
afterDeploy: async (deps) => {
const simpleStorage = deps.contracts.SimpleStorage; // this is the web3 instance created from an ABI
const value = await simpleStorage.methods.get().call();
console.log(value);
}
...
```
In order for Embark to create ready-to-use web3 Smart Contract instances,
it needs the contract's ABI. At the moment there are two possible ways to
achieve this for contracts we don't own:
1. Set the `address` of the already deployed contract and create a Solidity
interface with the same name of the existing Contract that matches that
Contract's interface. Embark is then going to compile that interface
which will output an ABI whic can be used for web3 instance creation.
2. If the source of the 3rd party Smart Contract is available, use the
`file` option to specify the path to the source, which Embark then picks
up for compilation. Again, this results in ABI code which is then used
for web3 instance creation.
As of now option 1) doesn't actually work, at least web3 is going to throw
an error when trying to access Smart Contract instances that have been created
that way. The reason for that is that the instance doesn't have a `deployedAddress`.
This commit ensures that the `deployedAddress` is set when the Smart Contract
config comes with a preconfigured `address`.
This commit automates our release process. It takes care of a couple of things:
- Bumps version number in package.json as needed, see below
- Generates changelog based on commit history
- Create release commit
- Tags release commit
- Pushes release commit including tags to upstream repository
- Publishes release on npm
There are a couple of options supported. The base command is run like this:
```
npm run release
```
This will do a minor bump and try to push to `origin` on `master`. However,
this can be altered with the following options.
```
npm run release -- --dry-run
```
Can be used to perform dry run and not actually committing, tagging, pushing,
publishing anything.
```
npm run release -- --release-as <something>
```
Something can be `minor`, `major`, `patch` or anything you want `foo`, `1.0.0` etc.
```
npm run release -- --prerelease alpha
```
Will create a prerelease version a la `4.0.0-alpha.x`.
```
npm run release -- --prerelease alpha --npm-dist-tag next
```
Publishes a dist tag on npm using dist tag `next`
```
npm run release -- --sign
```
Signs the release commit (you need to have PGP setup for that).
```
npm run release -- --repo-origin pascal --repo-branch foo/bar
```
Pushes the release commit into `pascal/foo/bar`.
Prior to this commits deployment lifecycle hooks had been defined as Array<string> due
to historical reasons (contracts.js) used to be a json file back in the days.
`deployIf`, `onDeploy` and `afterDeploy` can now be defined as (async)
function and have access to several dependencies such as contract instances and web3.
However, in order to have needed dependencies registered in the dependencies object,
all lifecycle hook dependencies need to be listed in the `deps` property
as shown below.
Also note that this is NOT a breaking change. Existing deployment lifecycle
hooks written in Array<string> style still work.
All three lifecycle hooks can now be defined as (async) functions and get an dependency
object with a shape like this:
```
interface DeploymentLifecycleHookDependencies {
contracts: Map<string, ContractInstance>;
web3: Web3Instance
}
```
`deployIf` lifecycle hook has to return a promise (or be defined using async/await and return
a value) like this:
```
contracts: {
MyToken: {...},
SimpleStorage: {
deps: ['MyToken'], // this is needed to make `MyToken` available within `dependencies`
deployIf: async (dependencies) => {
return dependencies.contracts.MyToken_address;
}
},
}
```
Vanilla promises (instead of async/await) can be used as well:
```
contracts: {
MyToken: {...},
SimpleStorage: {
deps: ['MyToken'],
deployIf: (dependencies) => {
return new Promise(resolve => resolve(dependencies.contracts.MyToken_address);
}
},
}
```
`onDeploy` as well, returns either a promise or is used using async/await:
```
contracts: {
SimpleStorage: {
onDeploy: async (dependencies) => {
const simpleStorage = dependencies.contracts.SimpleStorage;
const value = await simpleStorage.methods.get().call();
console.log(value);
}
},
}
```
`afterDeploy` has automatically access to all configured and deployed contracts of the dapp:
```
contracts: {
SimpleStorage: {...},
MyToken: {...},
afterDeploy: (dependencies) => {
console.log('Done!');
}
}
```
Closes#1029
yarn.lock files are generated for embark and embark-ui, and their package.json
files and other npm related files are updated to support and require using yarn
for development of embark itself and for embark's CI.
Buggy behavior related to npm lock files makes the goal of reproducible builds
and hassle-free automated releases nearly impossible to achieve at
present. With npm's lock files disabled we rely on pinned dependencies (exact
versions only in the package.json files of embark and embark-ui) for a
hopefully good result. This is an experiment while the project is in an alpha
release phase, and if problems are experienced we can return to using
npm-shrinkwrap.json / package-lock.json, or we can investigate a transition to
the yarn package manager, for ourselves and possibly for our users too.
Adds a --template option to the embark demo cli command so it is now possible to generate a demo project using an existing embark's template repository on Github with an existing demo branch (e.g. embark demo --template vue will use embark-framework/embark-vue-template#demo), or any other git URL repository. If no --template option is specified, the command will generate a demo from default template in templates/demo
This was a regression introduced in a web3 upgrade where `0x0` addresses where no longer
accepted as valid addresses and have to be replaced with full zero addresses.
This commit ensures that, if Embark apps still make use of `0x0` addresses in
their configs, they are properly replaced or extended to satisfy web3's APIs.
Fixes#956
In 594d1323fa we've introduced the ability
to configure balance-related options with human readable ether units.
There are cases where there's account configurations that don't come
with a `balance` property, which breaks Embark when running an Embark app.
Fixes#1067
Iuri Matias
Pascal Precht
Andre Medeiros
Richard Ramos
Jonathan Rainville
Filip Š
Anthony Laibe
Michael Bradley, Jr
Santiago Gonzalez Toral