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
Reintroduce NODE_PATH so that DApps with embark locally installed can properly
resolve modules supplied by embark. Refactor process.env related settings into
src/lib/core/env.js
Allow for embark sources to be authored in TypeScript and/or JavaScript, and to
make use of upcoming features of the JS language. Sources in the src/ directory
are transpiled into the dist/ directory, and npm-scripts are provided to
support and automate various aspect of the build process. Source map support is
enabled at runtime, i.e. when invoking the embark cli and running embark's test
suite.
