For all instances where a `Contract` instance is serialized using `JSON.stringify`, the `logger` property was being stringified and written to logs and contract artifact files.
Add Serializer class that allows ignoring of class properties during serialization when using `JSON.stringify`.
NOTE: The `Serializer` relies on TypeScript’s decorators which are still listed as experimental (requiring the necessary compiler flag) despite being around for several years. Decorators are a stage 2 proposal for JavaScript.
Enable putting `$accounts[i]` in subdomain registrations, where `i`
is the index of the `getAccounts` array.
This is the same behaviour we have for contract deployement
`Engine`s internal `coreComponents()` API sets up a bunch of things like
a `ProcessManager` and the `ServiceMonitor`. The `ServiceMonitor` activates
itself on `embark:engine:started` and practically monitors registered services
until the process has been explicitly stopped.
There are some commands that don't actually need service monitoring like `build` and
a future `exec` command that's in the making. For those cases it's useful to have them
disable the service monitor when `coreComponents()` is used.
This commit moves the `ServiceMonitor` instantiation out of `coreComponents()` and introduces
a new module group instead. This then lets commands that need service monitoring instantiate it
explicitly.
Before, `embark build` would wait at the end if there was an
afterDeploy, because there was no way with the old string and array
syntax to know when the commands were done.
Now, with the function syntax, we can wait for the end.
This way, we can exit the build at the end if it is a function
afterDeploy.
Otherwise, we show a message saying that they should update
Before, we checked if the network was a testnet or mainnet and
warned if there were no account sconfigured to sync. However, that
didn't take into account that we could connect to an external node,
hence not starting Geth at all.
So to fix that, I moved the condition and message to the Geth module
and only log when we start the node and the condition is met.
`packages/embark/src/cmd/dashboard/dashboard.js` overwrites the logger
instance's `logFunction` method with a method named `logEntry` defined on the
class exported from `packages/embark/src/cmd/dashboard/monitor.js`. Update
`logEntry` in the same way as `logFunction` was revised in #2184.
Also make a few more revisions:
Revise the "write logs" testing strategy such that it's not necessary for the
logger functions to take an optional callback.
Drop unused `tmp` package from `packages/core/logger` since it's not used in
the tests.
Strip colors before writing to the log file, use a two-space delimiter between
sections of each logged line in the log file, and collapse whitespace in the
message section of each line. These changes make the log file more amenable to
being processed with cli tools such as awk, cut, etc. It's also possible in a
text editor to replace `' '` with `\t` and then load the file in a spreadsheet,
with each line-section in its own column.
Rearrange the sections of each logged line so that it's easier to read, and
only include the origin if the loglevel is debug or trace.
The `"qa:full"` script comes into play in the contexts of
`scripts/release.js` (`npm run release`) and `scripts/stable-release.js`
(`npm run release:stable`).
Remove `bignumber.js` workaround (in the root, from PR #2152) because it's no
longer needed (verified locally).
Remove the `"skipLibCheck"` workaround (in `packages/plugins/solidity-tests`,
from PR #2152) because it's no longer needed (verified locally).
Refactor a typing in `packages/plugins/geth`. What's happening is that in web3
v1.2.4 `sendTransaction` has a return type of `PromiEvent<TransactionReceipt>`
but in v1.2.6 it has a return type of `PromiEvent<TransactionReceipt |
TransactionRevertInstructionError>`.
Compare:
* [v1.2.4/packages/web3-eth/types/index.d.ts#L291-L294](https://github.com/ethereum/web3.js/blob/v1.2.4/packages/web3-eth/types/index.d.ts#L291-L294)
* [v1.2.6/packages/web3-eth/types/index.d.ts#L295-L298](https://github.com/ethereum/web3.js/blob/v1.2.6/packages/web3-eth/types/index.d.ts#L295-L298)
The problem is that the `TransactionRevertInstructionError` type doesn't have a
`transactionHash` property. Since at present the code in
`packages/plugins/geth/src/devtxs.ts` only deals with the success case re:
`sendTransaction`, import the `TransactionReceipt` type from `web3-eth` and
cast the resolved return value's type using TypeScript's `as` operator.
This only affected the demo. We somehow put the `enableEthereum()`
call right before the Demo `set` function, so since we now throw
when it's not available, it stopped the `set`. But it was never
needed because demo has `autoEnadble` on, meaning that `enable` is
called at the start.
This follows on PR #2227.
Satisfy new peer dependencies following the bumps: `@storybook/core`,
`regenerator-runtime`.
Follow storybook's instructions to add `@storybook/preset-create-react-app` as
a dependency and also add the needed `.storybook/main.js` in
`packages/cockpit/ui/`.
Storybook is sensitive to presets being in the immediate project's
`node_modules` so add a `"nohoist"` in the root `package.json` for
`"embark-ui/@storybook/**"`.
After making the changes above, problems related to babel were observed when
running `yarn start`. It has been known for some time that having the root
babel config's dependencies spec'd in
`packages/utils/collective/package.json` (which is the package that actually
drives the babel cli) could lead to problems related to deduping, but such
problems hadn't been experienced until now. Move the dependencies relevant to
the root `babel.config.js` into the root `package.json` and update the
explanatory comment in the config.
registerSubDomain didn't work in tests because it used the old way
of checking the env, which is checking the `this.env` string, but in
tests, we use the `test` env. So instead, we now check if it is a
known network using the network ID (like we do for other place)
This was caused by the fact that we add the ENS contract to the
manager when before they deploy, but the dependency resolution was
done while building the contracts, so even before.
So the solution was to add a "before build" action so that the ENS
module could add its contracts to the manager if needed.
generateAll was async, but it called the write functions with a sync
loop, so at the end of the function, the files were not written yet.
This is a problem in `embark build` because the process ends after
genrateAll is done, so no artifacts were written
This results in faster completions on Azure Pipelines. For an individual
build (OS/Node.js combination) it shaves off ~10 or more minutes, depending on
the OS.
Once the `lint` and `test` steps have collective implementations we should be
able to shave another couple of minutes off of the completion times.
The steps that take the longest are `yarn install` (~4 minutes), collective
`typecheck` (~4 minutes), and `ci:dapps` (~3 minutes).
Make various related changes to templates, tests, etc. The methodology for
finding files that needed changes was to search through the whole monorepo for
the strings "solc" and "solidity" and then inspect the hits to see whether
changes were needed/appropriate.
Remove `solc` as a dependency in `packages/embark/package.json` so that it's
only a proper dependency in `packages/plugins/solidity/package.json`. Adjust
how the "bundled" `solc` package's version is determined, i.e. inspect the
`package.json` of `embark-solidity` instead of `embark`.
When `solc`'s version is `>=0.6.0` use the [new callback API][api].
[api]: https://github.com/ethereum/solc-js/blob/master/README.md#example-usage-with-import-callback
Changes the way the logs are stored to straight up be logged as an
array and then reads it as such. It also removes the reverse from
the read and puts it in the UI instead since it's the UI that needs
it reversed.
emizzle
Jonathan Rainville
Iuri Matias
EmbarkBot
Pascal Precht
Michael Bradley, Jr
dependabot-preview[bot]
Jinho Jang
Marc