Use proper stream parsing to consistently track JSON-RPC messages.
For HTTP POST requests use the `stream-json` package to assemble request and
response message objects.
For WebSocket requests continue to use `simples/lib/parsers/ws` to process
stream frames into messages. For Websocket responses use the Receiver class of
the `ws` package to process stream data into messages. In both cases, make use
of the `cloneable-readable` and `stream-chain` packages to avoid leaks.
This mishmash of stream parsing approaches is the result of much
experimentation to find a working solution. For example,
`simples/lib/parsers/ws` does't work for processing WebSocket responses and
`ws.Receiver` doesn't work for processing requests. Additional revisions may be
necessary.
Revise `blockchain_process/dev_funds.js` to use web3's HTTP provider if a DApp
disables the WebSocket proxy.
As discussed in #1121, the `eject-webpack` command in Embark's CLI
exposes implementation details of the CLI's build process, namely webpack.
If we ever change our internal build tooling, commands like this
will become obsolete immediately. That's why this commit introduces
a new command `eject-build-config`, with `eject-webpack` being an alias for it.
So the following commands are the same:
```
$ embark eject-build-config
```
and
```
$ embark eject-webpack
```
The `eject-webpack` command can now be marked as deprecated and removed in future
versions of Embark.
Closes#1121
This commit allows dapp developers to specify an ABI for contracts that are
already deployed and which source they don't own.
Prior to this commit there were two options to use web3 contract instances of 3rd
party contracts in Embark:
1. Define an interface for the 3rd party contract and have Embark compile that
2. Define path to source file of 3rd party contract and have Embark compile that
Both options result in Embark getting hold of the contracts ABI so it can be used
by web3 to create instances.
Now there's a third option that doesn't require creating an interface, nor the
source of the 3rd party contract.
Example:
```
// config/contracts.js
...
contracts: {
SimpleStorage: {
address: '0x0bFb07f9144729EEF54A9057Af0Fcf87aC7Cbba9',
abiDefinition: [...] // full ABI
}
},
afterDeploy: async(deps) => {
const simpleStorage = deps.contracts.SimpleStorage;
const value = await simpleStorage.methods.get().call();
console.log('value', value);
}
```
In d3f6b43986 we ensured that Embark automatically
expands `0x0` address to full zero addresses in order to stay backward compatible
with existing projects that made use of `0x0`, even after we've upgraded web3,
which doesn't allow that syntax anymore.
Turns out however, that the address expansion for `afterDeploy` hook was
done in the wrong place. This was due to a bug in our documentation that has been
fixed in 66a5bec46d
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.
Jonathan Rainville
Michael Bradley, Jr
Anthony Laibe
Pascal Precht
Iuri Matias
Andre Medeiros
Richard Ramos
Filip Š