embarklabs
/
embark
mirror of https://github.com/embarklabs/embark.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
embark/packages/plugins/scripts-runner/package.json

93 lines
2.2 KiB
JSON
Raw Normal View History

feat(plugins/scripts-runner): introduce exec command to run scripts 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
2020-02-04 10:47:12 +00:00
{
"name": "embark-scripts-runner",
chore(prerelease): 5.3.0-nightly.10
2020-03-14 00:16:39 +00:00
"version": "5.3.0-nightly.10",
feat(plugins/scripts-runner): introduce exec command to run scripts 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
2020-02-04 10:47:12 +00:00
"description": "Embark Scripts Runner",
"repository": {
"directory": "packages/plugins/scripts-runner",
"type": "git",
"url": "https://github.com/embarklabs/embark/"
},
"author": "Iuri Matias <iuri.matias@gmail.com>",
"license": "MIT",
"bugs": "https://github.com/embarklabs/embark/issues",
"keywords": [],
"files": [
fix: ensure that packages properly specify their dependencies 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`).
2020-02-20 23:47:01 +00:00
"dist",
"index.js"
feat(plugins/scripts-runner): introduce exec command to run scripts 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
2020-02-04 10:47:12 +00:00
],
fix: ensure that packages properly specify their dependencies 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`).
2020-02-20 23:47:01 +00:00
"main": "./index.js",
feat(plugins/scripts-runner): introduce exec command to run scripts 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
2020-02-04 10:47:12 +00:00
"types": "./dist/index.d.ts",
"embark-collective": {
"build:node": true,
"typecheck": true
},
"scripts": {
"_build": "npm run solo -- build",
"_typecheck": "npm run solo -- typecheck",
"ci": "npm run qa",
"clean": "npm run reset",
"lint": "npm-run-all lint:*",
fix: ensure that packages properly specify their dependencies 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`).
2020-02-20 23:47:01 +00:00
"lint:js": "eslint test/",
feat(plugins/scripts-runner): introduce exec command to run scripts 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
2020-02-04 10:47:12 +00:00
"lint:ts": "tslint -c tslint.json \"src/**/*.ts\"",
"qa": "npm-run-all lint _typecheck _build test",
"reset": "npx rimraf dist embark-*.tgz package",
"solo": "embark-solo",
"test": "jest"
},
fix: ensure that packages properly specify their dependencies 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`).
2020-02-20 23:47:01 +00:00
"eslintConfig": {
"extends": [
"../../../.eslintrc.json",
"plugin:jest/recommended",
"plugin:jest/style"
]
},
feat(plugins/scripts-runner): introduce exec command to run scripts 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
2020-02-04 10:47:12 +00:00
"dependencies": {
build(deps): bump @babel/runtime-corejs3 from 7.7.4 to 7.8.4 Bumps [@babel/runtime-corejs3](https://github.com/babel/babel) from 7.7.4 to 7.8.4. - [Release notes](https://github.com/babel/babel/releases) - [Changelog](https://github.com/babel/babel/blob/master/CHANGELOG.md) - [Commits](https://github.com/babel/babel/compare/v7.7.4...v7.8.4) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-03-04 07:58:38 +00:00
"@babel/runtime-corejs3": "7.8.4",
build(deps): bump async from 2.6.1 to 3.2.0 Bumps [async](https://github.com/caolan/async) from 2.6.1 to 3.2.0. - [Release notes](https://github.com/caolan/async/releases) - [Changelog](https://github.com/caolan/async/blob/master/CHANGELOG.md) - [Commits](https://github.com/caolan/async/compare/v2.6.1...v3.2.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-03-06 07:20:08 +00:00
"async": "3.2.0",
feat(plugins/scripts-runner): introduce exec command to run scripts 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
2020-02-04 10:47:12 +00:00
"core-js-pure": "3.6.4",
chore(prerelease): 5.3.0-nightly.10
2020-03-14 00:16:39 +00:00
"embark-core": "^5.3.0-nightly.10",
chore(prerelease): 5.3.0-nightly.5
2020-03-06 00:15:50 +00:00
"embark-i18n": "^5.3.0-nightly.5",
chore(prerelease): 5.3.0-nightly.6
2020-03-07 00:14:47 +00:00
"embark-logger": "^5.3.0-nightly.6",
chore(prerelease): 5.3.0-nightly.7
2020-03-10 00:18:09 +00:00
"embark-utils": "^5.3.0-nightly.7",
feat(plugins/scripts-runner): introduce exec command to run scripts 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
2020-02-04 10:47:12 +00:00
"fs-extra": "8.1.0",
fix: ensure that packages properly specify their dependencies 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`).
2020-02-20 23:47:01 +00:00
"web3": "1.2.6",
"web3-eth": "1.2.6"
feat(plugins/scripts-runner): introduce exec command to run scripts 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
2020-02-04 10:47:12 +00:00
},
"devDependencies": {
build(deps): bump @babel/core from 7.7.4 to 7.8.6 Bumps [@babel/core](https://github.com/babel/babel) from 7.7.4 to 7.8.6. - [Release notes](https://github.com/babel/babel/releases) - [Changelog](https://github.com/babel/babel/blob/master/CHANGELOG.md) - [Commits](https://github.com/babel/babel/compare/v7.7.4...v7.8.6) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-03-02 19:59:18 +00:00
"@babel/core": "7.8.6",
feat(plugins/scripts-runner): introduce exec command to run scripts 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
2020-02-04 10:47:12 +00:00
"@types/node": "^10.5.3",
"babel-jest": "24.9.0",
chore(release): 5.2.3
2020-02-25 21:09:29 +00:00
"embark-solo": "^5.2.3",
chore(prerelease): 5.3.0-nightly.6
2020-03-07 00:14:47 +00:00
"embark-testing": "^5.3.0-nightly.6",
fix: ensure that packages properly specify their dependencies 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`).
2020-02-20 23:47:01 +00:00
"eslint": "6.8.0",
build(deps-dev): bump eslint-plugin-jest from 22.5.1 to 23.8.1 Bumps [eslint-plugin-jest](https://github.com/jest-community/eslint-plugin-jest) from 22.5.1 to 23.8.1. - [Release notes](https://github.com/jest-community/eslint-plugin-jest/releases) - [Changelog](https://github.com/jest-community/eslint-plugin-jest/blob/master/CHANGELOG.md) - [Commits](https://github.com/jest-community/eslint-plugin-jest/compare/v22.5.1...v23.8.1) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-03-05 07:55:25 +00:00
"eslint-plugin-jest": "23.8.1",
build(deps-dev): bump jest from 24.9.0 to 25.1.0 Bumps [jest](https://github.com/facebook/jest) from 24.9.0 to 25.1.0. - [Release notes](https://github.com/facebook/jest/releases) - [Changelog](https://github.com/facebook/jest/blob/master/CHANGELOG.md) - [Commits](https://github.com/facebook/jest/compare/v24.9.0...v25.1.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>
2020-02-25 21:15:07 +00:00
"jest": "25.1.0",
feat(plugins/scripts-runner): introduce exec command to run scripts 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
2020-02-04 10:47:12 +00:00
"npm-run-all": "4.1.5",
"rimraf": "3.0.0",
fix: ensure that packages properly specify their dependencies 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`).
2020-02-20 23:47:01 +00:00
"sinon": "7.4.2",
"tmp-promise": "1.1.0",
"tslint": "5.20.1",
"typescript": "3.7.2"
feat(plugins/scripts-runner): introduce exec command to run scripts 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
2020-02-04 10:47:12 +00:00
},
"engines": {
"node": ">=10.17.0",
"npm": ">=6.11.3",
"yarn": ">=1.19.1"
},
"jest": {
"collectCoverage": true,
"testEnvironment": "node",
"testMatch": [
"**/test/**/*.js"
],
"transform": {
"\\.(js|ts)$": [
"babel-jest",
{
"rootMode": "upward"
}
]
}
}
}