There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
Data send from the client with GET parameters are serialized in the
request body's `params` property. As express doesn't seem to parse
those, we have to do it manually to perform object property traversals.
Fiddles are now stored in the filesystem so they can be preserved across page reloads, but also so that contracts deployed via fiddles can have their source code shown.
Fiddles deployed as contracts now fully work with existing contract list UI and functionality. Fiddle deployed contracts are listed in a separate section in the UI.
Current limitation is that only single contracts per file are supported. If the fiddle contains multiple contracts, it’s currently not supported.
Cargo in fact, bundles up subsequent tasks in to an array, so any tasks that are not immediately run get bundled in to another run later. This helps when lots of changes have been made in a short period of time.
For file changes that do not require a webpack run, ie HTML, the assets will still be copied to the output directory, but webpack will not run (as it’s too slow).
to configure pipeline specific options like TypeScript support.
At the time this has been added, `core/config` didn't handle the loading
of configuration files for pipeline related tasks yet.
This commit ensures a dapp's `pipeline.json` will be loaded and used to
configure Embark's webpack process as part of Embark's `Config` initialization.
This is the first step of refactoring Embark's pipeline abstraction into
dedicated plugin modules that take advantage of Embark's event system.
With this commit we're moving `Pipeline` into `lib/modules/pipeline` and
introduce a new command handler `pipeline:build`. Embark's engine now
requests builds via this command handler.
Notice that `Watch` still lives in `lib/pipeline` as this is a step-by-step
refactoring to reduce chances of introducing regressions.
emizzle
Pascal Precht
Anthony Laibe
Iuri Matias
Jonathan Rainville