`embark-snark` has been updated such that it can be used, in conjunction with `embarkjs-snark`, in the console, and in the DApp.
This could, for example, be used to build a dapp like https://tornado.cash.
Please see the README for usage instructions.
Updated tests were excluded in this PR as a consideration for time already spent on getting this library completed. Tests should be updated in a future PR.
chore: make basic-pipeline an optional plugin
chore: make basic-pipeline an optional plugin
chore: make basic-pipeline an optional plugin
chore: make basic-pipeline an optional plugin
chore: make basic-pipeline an optional plugin
chore: make basic-pipeline an optional plugin
chore: make basic-pipeline an optional plugin
fixes
address code review
fix linter issue
fix missing param
fix binding
remove pipeline warning
remove unused var
feat: support selecting what library to generate artifacts
feat: support selecting what library to generate artifacts
feat: support selecting what library to generate artifacts
feat: support selecting what library to generate artifacts
working web3 artifacts
remove unnecessary request
address code review issues
fixes
update tests
WIP: add index.js in packages/plugins/embarkjs/
This is a pattern established in #2285
remove comment
fix some code review issues
This commit introduces support for using `embark.config.js` to calculate the
embark configuration object that is otherwise provided via `embark.json`.
If an `embark.config.js` file is present, it will be used over the
`embark.json` file. The `embark.config.js` module needs to export either an
object or a function that can be asynchronous and has to return or resolve with
an embark configuration object:
```js
// embark.config.js
module.exports = async function () {
let config = ...; // do lazy calculation of `embarkConfig`;
return config;
}
```
Managing account details inside of the RPC Manager became a bit convulted and difficult to follow due to any web3 requests inside of an `RpcModifier` communicating over the proxy and therefore to other `RpcModifier`’s or itself. It also created cases where node accounts were duplicated by way of running the `eth_accounts` modifier multiple times (the first time getting accounts from the node and subsequent times getting accounts from the modified `eth_accounts` response.
This has been simplified by having the entry point of the `rpc-manager` (`index.js`) talk directly to the node via `web3`. This allowed account/nodeAccount management to also be handled by the entry point, removing the need for each individual `RpcModifier` from having to handle these account details. The result is a much more simplified and and much easier to maintain code for RPC Manager.
The cases for which accounts can be modified (via `personal_newAccount` RPC call, and via test configuration change) are now handled in one place (the entry point) and propagated to the each `RpcModifier`.
Add `blockchain:started` command to request when the blockchain has been started. In this case, this is needed so that we know when we can create a direct connection to the node, instead of the proxy (as is the case in almost all other modules).
Extend action timeout when in debug mode.
1. These changs have made the `RpcModifier` base class essentially useless, however, it has been kept in place because it will be used for future DRY improvements to the `rpc-manager`.
2. These changes have been tested with the following DApps:
- Demo
- Test DApp
- Contracts test DApp
- Teller
This commit introduces a new feature that enables users to calculate Smart Contract
constructor arguments lazily using an (async) function. Similar to normal Smart Contract
configurations, the return or resolved value from that function has to be either a list
of arguments in the order as they are needed for the constructor, or as an object with
named members that match the arguments individually.
```
...
development: {
deploy: {
SimpleStorage: {
args: async ({ contracts, web3, logger}) => {
// do something with `contracts` and `web3` to determine
// arguments
let someValue = await ...;
return [someValue];
// or
return {
initialValue: someValue
};
}
}
}
}
...
```
Closes#2270
feat(@embark/utils): add method to verify if a plugin is installed & configured
feature(@embark/utils): add method to verify if a plugin is installed & configured
feature: warn about packages that will be independent plugins and are not configured
chore: update templates to specify plugins
refactor: add to plugin api params so that blockchain plugins no longer need to be passed options
address changes in code review
remove unneded space
Update packages/core/utils/src/index.ts
Co-Authored-By: Jonathan Rainville <rainville.jonathan@gmail.com>
Update packages/core/utils/src/index.ts
Co-Authored-By: Michael Bradley <michaelsbradleyjr@gmail.com>
fix linting issue
add missing import
remove optional plugins from coming as default
Revert "chore: update hooks examples to destructure dependencies object"
This reverts commit 448eab724b.
remove trailing comma
fix linting issue
include tsconfig
The profiler was not formatted correctly in the console as `util.inspect` was being applied to the ASCII table before being output to the console REPL.
In addition, functions containing solidity assertions (require, revert, assert) that cause the function to fail when estimating gas would print an error to embark’s console log, and would show nothing as their gas estimate in the table.
Do not `util.inspect` command output if the result is a string. For API commands being run, allow the command to specify whether or not the output of the command should be HTML escaped. This could pose security risks!
For functions that have errors during gas estimation, add a message in the embark console explaining that the error may be due to solidity assertions in the function that prevent the gas from being estimated correctly. For functions that error, show `-ERROR-` in the gas estimation column. Additionally, show a description in the table footer explaining that the error may be due to solidity assertions in the function.
For events with no gas estimate, show `-EVENT-` in the gas estimate column of the profile table, and a description in the table footer explaining that there is no gas estimate for events.
### Warnings
This PR allows the console command to specify whether or not it should allow for a string result of the command to be HTML-escaped before being sent in the API response. Combining this with Cockpit’s `dangerouslySetInnerHTML`, this could allow a plugin to register a console command that injects XSS in to Cockpit.
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`).
fix(@embark/proxy): up max listener for proxy request manager
In the tests, we had warnings about max listeners reached, because
the default limit is 10. So I upped the limit for the request
manager and the WS connection.
stoopid CI
Set Ganache as a blockchain client that doesn't need to be started.
Set it as the default client, at least for development.
Move all blockchain related stuff in the blockchain component
Includes a fix by @emmizle to fix the WS connection in the proxy
feat(@embark/utils): add method to verify if a plugin is installed & configured
feature(@embark/utils): add method to verify if a plugin is installed & configured
feature: warn about packages that will be independent plugins and are not configured
chore: update templates to specify plugins
refactor: add to plugin api params so that blockchain plugins no longer need to be passed options
address changes in code review
remove unneded space
Update packages/core/utils/src/index.ts
Co-Authored-By: Jonathan Rainville <rainville.jonathan@gmail.com>
Update packages/core/utils/src/index.ts
Co-Authored-By: Michael Bradley <michaelsbradleyjr@gmail.com>
fix linting issue
add missing import
update dependency
fix plugins object
add missing whitespace
This commit introduces a new feature that enables users to run (migration) scripts.
Similar to deployment hooks, scripts are functions that may perform operations on newly
deployed Smart Contracts.
Therefore a script needs to export a function that has access to some dependencies:
```
// scripts/001-some-script.js
module.exports = async ({contracts, web3, logger}) => {
...
};
```
Where `contracts` is a map of newly deployed Smart Contract instances, `web3` a blockchain connector
instance and `logger` Embark's logger instance. Script functions can but don't have to be `async`.
To execute such a script users use the newly introduced `exec` command:
```
$ embark exec development scripts/001-some-script.js
```
In the example above, `development` defines the environment in which Smart Contracts are being
deployed to as well as where tracking data is stored.
Alternativey, users can also provide a directory in which case Embark will try to execute every
script living inside of it:
```
$ embark exec development scripts
```
Scripts can fail and therefore emit an error accordingly. When this happens, Embark will
abort the script execution (in case multiple are scheduled to run) and informs the user
about the original error:
```
.. 001_foo.js running....
Script '001_foo.js' failed to execute. Original error: Error: Some error
```
It's recommended for scripts to emit proper instances of `Error`.
(Migration) scripts can be tracked as well but there are a couple of rules to be aware of:
- Generally, tracking all scripts that have been executed by default is not a good thing because
some scripts might be one-off operations.
- OTOH, there might be scripts that should always be tracked by default
- Therefore, we introduce a dedicated `migrations` directory in which scripts live that should be
tracked by default
- Any other scripts that does not live in the specified `migrations` directory will not be tracked **unless**
- The new `--track` option was provided
For more information see: https://notes.status.im/h8XwB7xkR7GKnfNh6OnPMQ
Adds back the watch on contract events and writes them to a file
with the same method as contract logs from transaction-logger, so
I extracted those methods to utils/file so that both could use the
same functions.
EmbarkBot
emizzle
Iuri Matias
dependabot-preview[bot]
Michael Bradley, Jr
Pascal Precht
Jonathan Rainville
