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.
## User reported error
i recently updated to embark 5.0 im having issues connecting to a local node each time i connect to it i get the following output from the embark console
```
Error during proxy setup: Port should be >= 0 and < 65536. Received 754510.. Use '--loglevel debug' for more detailed information.
```
This is what i have under the blockchain.js file
```
localDev: {
endpoint: "http://127.0.0.1:7545",
accounts: [{
nodeAccounts: true,
}]
}
```
### Problem
The port to start the proxy on is incremented by a constant value (using the `+` operator), however the port comes from the config and in the case where it is a string, the `+` operator acts as a string concatentation.
### Fix
Ensure the port from the config is always parsed to a number before attempting to add the constant proxy port offset.
Also, in `dapps/tests/contracts` move the `this.timeout(0);` inside the
`it(...)` for the expensive gas esimation (involving
`SimpleStorage.methods.set`) because it otherwise doesn't seem to have an
effect on the default 15 second timeout.
When we introduced dappConnection to ENS, we didn't add the concept
of auto connection, like we do in the "normal" connection. This
means that when using $WEB3, the contracts connection waited for
the user to click on a button, but the ENS part called `ethereum.enable`
directly, which is confusing for the dev, because we specified to
NOT automatically connect to ethreum.
This fixes it by checking the dappAutoEnable property in contracts
config and adds it to the namesystemConfig artifact
And remove `suggestions.json` in the `"files"` list of
`packages/core/console/package.json` since it was moved to
`packages/plugins/suggestions/suggestions.json`.
Remove the `<12.0.0` restriction re: Node.js version in the `"engines"`
settings for all the packages in the monorepo that had that restriction.
Add missing `"engines"` settings in `packages/plugins/snark/package.json`.
Adjust the Azure Pipelines config to include builds for Node.js v12.x and
v13.x.
Bump `solc` to `0.4.26` in `dapps/tests/app` and `dapps/tests/contracts`. It
was discovered that older versions suffered a fatal `Maximum call stack size
exceeded` error when run on Windows with Node.js v12.x or newer. Display a
warning re: the bad combo (solc version + Windows + Node version) if it's
detected at runtime.
Adjust the root `yarn.lock` so that the `sha3` transitive dependency resolves
to a newer version that is compatible with Node v13.x.
Jonathan Rainville
Michael Bradley, Jr
EmbarkBot
dependabot-preview[bot]
Iuri Matias
Pascal Precht
Jinho Jang
Marc
emizzle