When making `basic-pipeline` in 948956ab1f we've introduced a regression
and with this fix, a behaviour change as well::
1. The `webpackConfigName` passed to `Engine` is completely ignored, caused it to be
`undefined` down the line when the plugin tries to do its work (we essentially broke bundling)
2. With that configuration being ignored, we need a new way to make this configurable.
Since `basic-pipeline` is now a true plugin, it makes sense for itself to have configuration
options for that, while still providing decent defaults.
3. The trickly thing is that `webpackConfigName` used to have different values per command.
For example `build` used to use `production` while `run` used `development` as config.
4. This commit introduces new configuration options for `basic-pipeline` that lets users configure
the `webpackConfigName` per environment:
```json
// embark.json
{
...
"plugins": {
"embark-basic-pipeline": {
"development": {
webpackConfigName: "development"
},
"production": {
webpackConfigName: "production"
}
}
}
}
```
^ These are also the defaults. So not providing this configuration will make
Embark imply it.
Notice that this does not account for the "different config per command" case.
This means `embark build` will also use `development` by default.
Prior to this commit and the one mentioned above, the `webpackConfigName` was configurable
through the CMD `--pipeline` option. Since this a) no longer a built-in feature
and b) ignored at the moment anyways, I've removed the `--pipeline` options
from all commands as well.
BREAKING CHANGES
The commands `embark eject-webpack` and `embark eject-build-config` are no longer available.
The `--pipeline` option has been removed from all commands that used to support it.
This commit introduces a new feature that enables users to run (migration) scripts.
Similar to deployment hooks, scripts are functions that may perform operations on newly
deployed Smart Contracts.
Therefore a script needs to export a function that has access to some dependencies:
```
// scripts/001-some-script.js
module.exports = async ({contracts, web3, logger}) => {
...
};
```
Where `contracts` is a map of newly deployed Smart Contract instances, `web3` a blockchain connector
instance and `logger` Embark's logger instance. Script functions can but don't have to be `async`.
To execute such a script users use the newly introduced `exec` command:
```
$ embark exec development scripts/001-some-script.js
```
In the example above, `development` defines the environment in which Smart Contracts are being
deployed to as well as where tracking data is stored.
Alternativey, users can also provide a directory in which case Embark will try to execute every
script living inside of it:
```
$ embark exec development scripts
```
Scripts can fail and therefore emit an error accordingly. When this happens, Embark will
abort the script execution (in case multiple are scheduled to run) and informs the user
about the original error:
```
.. 001_foo.js running....
Script '001_foo.js' failed to execute. Original error: Error: Some error
```
It's recommended for scripts to emit proper instances of `Error`.
(Migration) scripts can be tracked as well but there are a couple of rules to be aware of:
- Generally, tracking all scripts that have been executed by default is not a good thing because
some scripts might be one-off operations.
- OTOH, there might be scripts that should always be tracked by default
- Therefore, we introduce a dedicated `migrations` directory in which scripts live that should be
tracked by default
- Any other scripts that does not live in the specified `migrations` directory will not be tracked **unless**
- The new `--track` option was provided
For more information see: https://notes.status.im/h8XwB7xkR7GKnfNh6OnPMQ
Pascal Precht
emizzle