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`).
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.
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
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.
Michael Bradley, Jr
EmbarkBot
dependabot-preview[bot]
Jonathan Rainville
Iuri Matias