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
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.
Fixes the use of Infura to connect to the ENS contracts. When
connecting directly to Infura, it would throw with `rejected due to
project ID settings`, because it doesn't accept the VM as the domain
Instead, when passing from the proxy, it works. So I changed the
default when no dappConnection to ['$EMBARK']. I also added a
message when the error happens to help users fix it themselves
When in the testnet, we don,t register because we already have the
addresses, which is fine, but we also didn't populate the ensConfig
object which contains the important information about the addresses
and ABI.
There was a lot of lint problems in a couple of files so I cleaned
that up
## Problem
Doing read, then write each a trasaction or call exectues could get
heavy, especially with regular txs on
This was especially true in the tests, which led to deactivate the
tx logger in the tests
## Solution
Instead of reading the whole file, adding the JSON line a writing,
we instead just append some pseudo JSON to it that later gets read
and parsed correctly back to JSON
EmbarkBot
Michael Bradley, Jr
Jonathan Rainville
dependabot-preview[bot]
Iuri Matias
Pascal Precht
Marc
emizzle