Many packages in the monorepo did not specify all of their dependencies; they
were effectively relying on resolution in the monorepo's root
`node_modules`. In a production release of `embark` and `embark[js]-*` packages
this can lead to broken packages.
To fix the problem currently and to help prevent it from happening again, make
use of the `eslint-plugin-import` package's `import/no-extraneous-dependencies`
and `import/no-unresolved` rules. In the root `tslint.json` set
`"no-implicit-dependencies": true`, wich is the tslint equivalent of
`import/no-extraneous-dependencies`; there is no tslint equivalent for
`import/no-unresolved`, but we will eventually replace tslint with an eslint
configuration that checks both `.js` and `.ts` files.
For `import/no-unresolved` to work in our monorepo setup, in most packages add
an `index.js` that has:
```js
module.exports = require('./dist'); // or './dist/lib' in some cases
```
And point `"main"` in `package.json` to `"./index.js"`. Despite what's
indicated in npm's documentation for `package.json`, it's also necessary to add
`"index.js"` to the `"files"` array.
Make sure that all `.js` files that can and should be linted are in fact
linted. For example, files in `packages/embark/src/cmd/` weren't being linted
and many test suites weren't being linted.
Bump all relevant packages to `eslint@6.8.0`.
Fix all linter errors that arose after these changes.
Implement a `check-yarn-lock` script that's run as part of `"ci:full"` and
`"qa:full"`, and can manually be invoked via `yarn cylock` in the root of the
monorepo. The script exits with error if any specifiers are found in
`yarn.lock` for `embark[js][-*]` and/or `@embarklabs/*` (with a few exceptions,
cf. `scripts/check-yarn-lock.js`).
Requested here https://github.com/embarklabs/embark/issues/1689
Adds proxyFor to contracts that merges the ABI of the parent
contract to the child (proxy) contract so that the proxy can use
the methods of the parent but is deployed as itself
Turns out that 17cec1b787 has never worked as intended.
Custom provided `abiDefinition` values have been simply ignored. Embark always used the
`abiDefnition` that resulted from the Smart Contract compilation.
This was an issue experienced with ENS contracts not being deployed
because the configs used `strategy: explicit` and ENS configs are
not in configs.
To fix, I changed the way we check for deploy. If `deploy` is set as
`true` it should always deploy even if not in configs. It just means
they were added from a plugin (like ENS)
Also, I needed to set to `false` the `deploy` property of contracts
compiled that were not in config, because otherwise, they tried to
deploy, which goes against the strategy. This is because those
contracts get initiated as `deploy: true`.
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.
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 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.
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.
Refactor typings as necessary. In order for `bignumber.js` in the root
`node_modules` to not conflict with `@types/bignumber.js`, specify
`"bignumber.js": "5.0.0"` in `devDependencies` and `"embark-ui/bignumber.js"`
in `nohoist` of the root `package.json`.
In `packages/plugins/rpc-manager` switch from callback to promise usage with
respect to `web3.eth.accounts.signTransaction` because of a [bug][bug]
discovered in web3 v1.2.4.
In `packages/plugins/solidity-tests` specialize the tsc compiler options with
`"skipLibCheck": true` because of a problematic web3-related typing in the
`.d.ts` files of the remix-tests package.
Bump ganache-cli from 6.4.3 to 6.7.0 (latest) because 6.4.3 doesn't support
`eth_chainId` but web3 1.2.4 makes use of the `eth_chainId` RPC method (EIP
695).
BREAKING CHANGE: bump embark's minimum supported version of parity from
`>=2.0.0` to `>=2.2.1`. This is necessary since web3 1.2.4 makes use of the
`eth_chainId` RPC method (EIP 695) and that parity version is the earliest one
to implement it.
[bug]: https://github.com/ethereum/web3.js/issues/3283
This fixes a bug that redeployment of contracts has not been properly
reflected in the cockpit contract list.
The reason for that was that it's listening for a websocket API that
only updates when the `contractsState` event has been emitted.
The commit ensures `contractsState` is emitted during dedicated deployment
events.
EmbarkBot
dependabot-preview[bot]
Iuri Matias
Pascal Precht
Michael Bradley, Jr
Jonathan Rainville
emizzle