embark/package.json

231 lines
7.5 KiB
JSON
Raw Normal View History

2015-05-24 12:38:56 +00:00
{
"name": "embark",
2019-01-10 18:07:10 +00:00
"version": "4.0.0-beta.0",
"author": "Iuri Matias <iuri.matias@gmail.com>",
"contributors": [],
2016-10-02 23:01:10 +00:00
"description": "Embark is a framework that allows you to easily develop and deploy DApps",
"homepage": "https://embark.status.im/",
"keywords": [
2018-10-24 18:50:25 +00:00
"blockchain",
"dapps",
2018-10-24 18:50:25 +00:00
"ethereum",
"ipfs",
2018-10-24 18:50:25 +00:00
"serverless",
"solc",
2018-10-24 18:50:25 +00:00
"solidity"
],
"license": "MIT",
"repository": {
"type": "git",
"url": "https://github.com/embark-framework/embark.git"
},
"bin": {
"embark": "./bin/embark"
},
"main": "./dist/lib/index.js",
2015-05-24 12:38:56 +00:00
"scripts": {
"babel": "babel",
"babel:node": "npm-run-all babel:node:*",
"babel:node:src": "cross-env BABEL_ENV=node babel src --copy-files --extensions \".js,.ts\" --out-dir dist --source-maps",
"babel:watch": "run-p babel:watch:*",
"babel:watch:src": "npm run babel:node:src -- --verbose --watch",
"build": "npm-run-all build:*",
"build:node": "npm run babel:node",
"build:ui": "cd embark-ui && npm run build",
build: introduce a `prepare` script in embark's package.json **TL;DR** These changes affect workflow with yarn. To prevent embark's `prepare` script from running undesirably: - If node_modules is in place and you're reinstalling after switching branches: ``` yarn run install_all ``` - If node_modules is missing (fresh clone or deleted): ``` EMBARK_NO_PREPARE=t yarn install && yarn run install_all ``` It's not recommended to set `EMBARK_NO_PREPARE` in your environment (e.g. in `.bashrc`) since that would interfere with embark's `release` script if/when you run it. ----------------- **1.** Specify embark's build-related steps in the `prepare` script of package.json. When embark is installed directly from GitHub the `prepare` script results in a "pre install" phase (handled automatically by npm/yarn) that fetches devDependencies, builds embark (including embark-ui), packs a tarball with the same steps (minus testing and tree-checking) as would happen during an embark release, and finally does a production install from that tarball. Important point: installs from GitHub must be performed with yarn; they're no longer possible with npm since during the "pre install" phase npm will honor embark's `.npmrc` and `"engines"` settings. The following will work correctly after this commit is merged: ``` yarn [global] add git+https://github.com/embark-framework/embark.git ``` Use of "hosted git" shortcuts (e.g. `embark-framework/embark#bracnh`) won't work correctly because yarn doesn't fully support them. See: https://github.com/yarnpkg/yarn/issues/5235. It's important to use `git+https` urls. Following a succesful install with `git+https` it is possible to use a "hosted git" shortcut or `https` url, but that's owing to a subtle and unreliable interaction between yarn's cache and yarn's logic for installing from a url/shortcut. **2.** Adjust the npm configs (`.npmrc`) for embark/-ui so that `yarn run [cmd] [--opt]` can be used in place of `npm run [cmd] -- [--opt]`. Either way is okay for running scripts, they're equivalent, but note the requirement to use `--` before specifying command options with `npm run`. **3.** Introduce yarn configs (`.yarnrc`) for embark/-ui and include the `check-files` directive. H/t to @alaibe for the recommendation. **4.** Ignore embark's `dist/typings` and `scripts` directories when packing a tarball. **5.** Refactor embark/-ui's npm-scripts in relation to the `prepare` script, and make other small improvements. Notably, if the environment variable `EMBARK_NO_PREPARE` is truthy (from JS perspective) then embark's `prepare` script will exit early. This prevents `install_all` and `prepare` from getting stuck in a loop (`install:core` uses cross-env to set `EMBARK_NO_PREPARE`) and provides a mechanism for users to skip the `prepare` script when doing a fresh install: ``` EMBARK_NO_PREPARE=t yarn install ``` **6.** Give `.js` extensions to node scripts in embark's `scripts/`, remove the shebang lines, and have npm-scripts explicitly invoke them with node. This arrangement works for all platforms: Linux, macOS, and Windows. **7.** Adjust travis and appveyor configs. Since at present there aren't any tests or other CI steps that make use of embark-ui's production build, set `EMBARK_NO_PREPARE` in the CI environments and invoke `build:node` directly. Check the working tree after `yarn install` for embark/-ui. This detects situations where changes should have been committed to `yarn.lock` but were not. Check the working tree again at the end to detect situations where ignore files should have been adjusted but were not. Both checks could also detect other surprising behavior that needs to be investigated. Any time the working tree is not clean (there are untracked files or changes) CI will fail. Drop CI runs for node 8.11.3 because that version ships with an older npm that results in unstaged changes to the test apps' `package-lock.json` files, causing the working tree check to fail at the end of the CI run. A simple workaround isn't apparent, but the matter can be revisited. **8.** Refactor embark's `release` script in light of the `prepare` script. Notably, do the push step only after `npm publish` completes successfully. This allows embark's `prepare` and `prepublishOnly` scripts to detect problems before a commit and tag are pushed to GitHub, avoiding a need to rebase/revert the remote release branch; the local branch will still need to have a commit dropped and tag deleted before rerunning the `release` script. Prompt the user if the `release` script is not being run in `--dry-run` mode. Provide additional visual indicators of `--dry-run` mode. Force the user to supply `--repo-branch [branch]` if the intention is to release from a branch other than `master`.
2018-11-19 19:11:57 +00:00
"check-no-prepare": "node scripts/check-no-prepare.js",
"check-working-tree": "node scripts/check-working-tree.js",
"clean": "npm-run-all clean:*",
"clean:core": "rimraf dist embark-*.tgz package",
"clean:ui": "cd embark-ui && npm run clean",
"eslint": "eslint",
build: introduce a `prepare` script in embark's package.json **TL;DR** These changes affect workflow with yarn. To prevent embark's `prepare` script from running undesirably: - If node_modules is in place and you're reinstalling after switching branches: ``` yarn run install_all ``` - If node_modules is missing (fresh clone or deleted): ``` EMBARK_NO_PREPARE=t yarn install && yarn run install_all ``` It's not recommended to set `EMBARK_NO_PREPARE` in your environment (e.g. in `.bashrc`) since that would interfere with embark's `release` script if/when you run it. ----------------- **1.** Specify embark's build-related steps in the `prepare` script of package.json. When embark is installed directly from GitHub the `prepare` script results in a "pre install" phase (handled automatically by npm/yarn) that fetches devDependencies, builds embark (including embark-ui), packs a tarball with the same steps (minus testing and tree-checking) as would happen during an embark release, and finally does a production install from that tarball. Important point: installs from GitHub must be performed with yarn; they're no longer possible with npm since during the "pre install" phase npm will honor embark's `.npmrc` and `"engines"` settings. The following will work correctly after this commit is merged: ``` yarn [global] add git+https://github.com/embark-framework/embark.git ``` Use of "hosted git" shortcuts (e.g. `embark-framework/embark#bracnh`) won't work correctly because yarn doesn't fully support them. See: https://github.com/yarnpkg/yarn/issues/5235. It's important to use `git+https` urls. Following a succesful install with `git+https` it is possible to use a "hosted git" shortcut or `https` url, but that's owing to a subtle and unreliable interaction between yarn's cache and yarn's logic for installing from a url/shortcut. **2.** Adjust the npm configs (`.npmrc`) for embark/-ui so that `yarn run [cmd] [--opt]` can be used in place of `npm run [cmd] -- [--opt]`. Either way is okay for running scripts, they're equivalent, but note the requirement to use `--` before specifying command options with `npm run`. **3.** Introduce yarn configs (`.yarnrc`) for embark/-ui and include the `check-files` directive. H/t to @alaibe for the recommendation. **4.** Ignore embark's `dist/typings` and `scripts` directories when packing a tarball. **5.** Refactor embark/-ui's npm-scripts in relation to the `prepare` script, and make other small improvements. Notably, if the environment variable `EMBARK_NO_PREPARE` is truthy (from JS perspective) then embark's `prepare` script will exit early. This prevents `install_all` and `prepare` from getting stuck in a loop (`install:core` uses cross-env to set `EMBARK_NO_PREPARE`) and provides a mechanism for users to skip the `prepare` script when doing a fresh install: ``` EMBARK_NO_PREPARE=t yarn install ``` **6.** Give `.js` extensions to node scripts in embark's `scripts/`, remove the shebang lines, and have npm-scripts explicitly invoke them with node. This arrangement works for all platforms: Linux, macOS, and Windows. **7.** Adjust travis and appveyor configs. Since at present there aren't any tests or other CI steps that make use of embark-ui's production build, set `EMBARK_NO_PREPARE` in the CI environments and invoke `build:node` directly. Check the working tree after `yarn install` for embark/-ui. This detects situations where changes should have been committed to `yarn.lock` but were not. Check the working tree again at the end to detect situations where ignore files should have been adjusted but were not. Both checks could also detect other surprising behavior that needs to be investigated. Any time the working tree is not clean (there are untracked files or changes) CI will fail. Drop CI runs for node 8.11.3 because that version ships with an older npm that results in unstaged changes to the test apps' `package-lock.json` files, causing the working tree check to fail at the end of the CI run. A simple workaround isn't apparent, but the matter can be revisited. **8.** Refactor embark's `release` script in light of the `prepare` script. Notably, do the push step only after `npm publish` completes successfully. This allows embark's `prepare` and `prepublishOnly` scripts to detect problems before a commit and tag are pushed to GitHub, avoiding a need to rebase/revert the remote release branch; the local branch will still need to have a commit dropped and tag deleted before rerunning the `release` script. Prompt the user if the `release` script is not being run in `--dry-run` mode. Provide additional visual indicators of `--dry-run` mode. Force the user to supply `--repo-branch [branch]` if the intention is to release from a branch other than `master`.
2018-11-19 19:11:57 +00:00
"install:core": "cross-env EMBARK_NO_PREPARE=t yarn install",
"install:ui": "cd embark-ui && yarn install",
"install_all": "npm-run-all install:*",
"lint": "npm-run-all lint:*",
"lint:js": "npm-run-all lint:js:*",
build: introduce a `prepare` script in embark's package.json **TL;DR** These changes affect workflow with yarn. To prevent embark's `prepare` script from running undesirably: - If node_modules is in place and you're reinstalling after switching branches: ``` yarn run install_all ``` - If node_modules is missing (fresh clone or deleted): ``` EMBARK_NO_PREPARE=t yarn install && yarn run install_all ``` It's not recommended to set `EMBARK_NO_PREPARE` in your environment (e.g. in `.bashrc`) since that would interfere with embark's `release` script if/when you run it. ----------------- **1.** Specify embark's build-related steps in the `prepare` script of package.json. When embark is installed directly from GitHub the `prepare` script results in a "pre install" phase (handled automatically by npm/yarn) that fetches devDependencies, builds embark (including embark-ui), packs a tarball with the same steps (minus testing and tree-checking) as would happen during an embark release, and finally does a production install from that tarball. Important point: installs from GitHub must be performed with yarn; they're no longer possible with npm since during the "pre install" phase npm will honor embark's `.npmrc` and `"engines"` settings. The following will work correctly after this commit is merged: ``` yarn [global] add git+https://github.com/embark-framework/embark.git ``` Use of "hosted git" shortcuts (e.g. `embark-framework/embark#bracnh`) won't work correctly because yarn doesn't fully support them. See: https://github.com/yarnpkg/yarn/issues/5235. It's important to use `git+https` urls. Following a succesful install with `git+https` it is possible to use a "hosted git" shortcut or `https` url, but that's owing to a subtle and unreliable interaction between yarn's cache and yarn's logic for installing from a url/shortcut. **2.** Adjust the npm configs (`.npmrc`) for embark/-ui so that `yarn run [cmd] [--opt]` can be used in place of `npm run [cmd] -- [--opt]`. Either way is okay for running scripts, they're equivalent, but note the requirement to use `--` before specifying command options with `npm run`. **3.** Introduce yarn configs (`.yarnrc`) for embark/-ui and include the `check-files` directive. H/t to @alaibe for the recommendation. **4.** Ignore embark's `dist/typings` and `scripts` directories when packing a tarball. **5.** Refactor embark/-ui's npm-scripts in relation to the `prepare` script, and make other small improvements. Notably, if the environment variable `EMBARK_NO_PREPARE` is truthy (from JS perspective) then embark's `prepare` script will exit early. This prevents `install_all` and `prepare` from getting stuck in a loop (`install:core` uses cross-env to set `EMBARK_NO_PREPARE`) and provides a mechanism for users to skip the `prepare` script when doing a fresh install: ``` EMBARK_NO_PREPARE=t yarn install ``` **6.** Give `.js` extensions to node scripts in embark's `scripts/`, remove the shebang lines, and have npm-scripts explicitly invoke them with node. This arrangement works for all platforms: Linux, macOS, and Windows. **7.** Adjust travis and appveyor configs. Since at present there aren't any tests or other CI steps that make use of embark-ui's production build, set `EMBARK_NO_PREPARE` in the CI environments and invoke `build:node` directly. Check the working tree after `yarn install` for embark/-ui. This detects situations where changes should have been committed to `yarn.lock` but were not. Check the working tree again at the end to detect situations where ignore files should have been adjusted but were not. Both checks could also detect other surprising behavior that needs to be investigated. Any time the working tree is not clean (there are untracked files or changes) CI will fail. Drop CI runs for node 8.11.3 because that version ships with an older npm that results in unstaged changes to the test apps' `package-lock.json` files, causing the working tree check to fail at the end of the CI run. A simple workaround isn't apparent, but the matter can be revisited. **8.** Refactor embark's `release` script in light of the `prepare` script. Notably, do the push step only after `npm publish` completes successfully. This allows embark's `prepare` and `prepublishOnly` scripts to detect problems before a commit and tag are pushed to GitHub, avoiding a need to rebase/revert the remote release branch; the local branch will still need to have a commit dropped and tag deleted before rerunning the `release` script. Prompt the user if the `release` script is not being run in `--dry-run` mode. Provide additional visual indicators of `--dry-run` mode. Force the user to supply `--repo-branch [branch]` if the intention is to release from a branch other than `master`.
2018-11-19 19:11:57 +00:00
"lint:js:core": "eslint babel.config.js bin/embark scripts/ src/bin/ src/lib/",
"lint:js:ui": "cd embark-ui && npm run lint",
"lint:ts": "tslint -c tslint.json 'src/**/*.ts'",
build: introduce a `prepare` script in embark's package.json **TL;DR** These changes affect workflow with yarn. To prevent embark's `prepare` script from running undesirably: - If node_modules is in place and you're reinstalling after switching branches: ``` yarn run install_all ``` - If node_modules is missing (fresh clone or deleted): ``` EMBARK_NO_PREPARE=t yarn install && yarn run install_all ``` It's not recommended to set `EMBARK_NO_PREPARE` in your environment (e.g. in `.bashrc`) since that would interfere with embark's `release` script if/when you run it. ----------------- **1.** Specify embark's build-related steps in the `prepare` script of package.json. When embark is installed directly from GitHub the `prepare` script results in a "pre install" phase (handled automatically by npm/yarn) that fetches devDependencies, builds embark (including embark-ui), packs a tarball with the same steps (minus testing and tree-checking) as would happen during an embark release, and finally does a production install from that tarball. Important point: installs from GitHub must be performed with yarn; they're no longer possible with npm since during the "pre install" phase npm will honor embark's `.npmrc` and `"engines"` settings. The following will work correctly after this commit is merged: ``` yarn [global] add git+https://github.com/embark-framework/embark.git ``` Use of "hosted git" shortcuts (e.g. `embark-framework/embark#bracnh`) won't work correctly because yarn doesn't fully support them. See: https://github.com/yarnpkg/yarn/issues/5235. It's important to use `git+https` urls. Following a succesful install with `git+https` it is possible to use a "hosted git" shortcut or `https` url, but that's owing to a subtle and unreliable interaction between yarn's cache and yarn's logic for installing from a url/shortcut. **2.** Adjust the npm configs (`.npmrc`) for embark/-ui so that `yarn run [cmd] [--opt]` can be used in place of `npm run [cmd] -- [--opt]`. Either way is okay for running scripts, they're equivalent, but note the requirement to use `--` before specifying command options with `npm run`. **3.** Introduce yarn configs (`.yarnrc`) for embark/-ui and include the `check-files` directive. H/t to @alaibe for the recommendation. **4.** Ignore embark's `dist/typings` and `scripts` directories when packing a tarball. **5.** Refactor embark/-ui's npm-scripts in relation to the `prepare` script, and make other small improvements. Notably, if the environment variable `EMBARK_NO_PREPARE` is truthy (from JS perspective) then embark's `prepare` script will exit early. This prevents `install_all` and `prepare` from getting stuck in a loop (`install:core` uses cross-env to set `EMBARK_NO_PREPARE`) and provides a mechanism for users to skip the `prepare` script when doing a fresh install: ``` EMBARK_NO_PREPARE=t yarn install ``` **6.** Give `.js` extensions to node scripts in embark's `scripts/`, remove the shebang lines, and have npm-scripts explicitly invoke them with node. This arrangement works for all platforms: Linux, macOS, and Windows. **7.** Adjust travis and appveyor configs. Since at present there aren't any tests or other CI steps that make use of embark-ui's production build, set `EMBARK_NO_PREPARE` in the CI environments and invoke `build:node` directly. Check the working tree after `yarn install` for embark/-ui. This detects situations where changes should have been committed to `yarn.lock` but were not. Check the working tree again at the end to detect situations where ignore files should have been adjusted but were not. Both checks could also detect other surprising behavior that needs to be investigated. Any time the working tree is not clean (there are untracked files or changes) CI will fail. Drop CI runs for node 8.11.3 because that version ships with an older npm that results in unstaged changes to the test apps' `package-lock.json` files, causing the working tree check to fail at the end of the CI run. A simple workaround isn't apparent, but the matter can be revisited. **8.** Refactor embark's `release` script in light of the `prepare` script. Notably, do the push step only after `npm publish` completes successfully. This allows embark's `prepare` and `prepublishOnly` scripts to detect problems before a commit and tag are pushed to GitHub, avoiding a need to rebase/revert the remote release branch; the local branch will still need to have a commit dropped and tag deleted before rerunning the `release` script. Prompt the user if the `release` script is not being run in `--dry-run` mode. Provide additional visual indicators of `--dry-run` mode. Force the user to supply `--repo-branch [branch]` if the intention is to release from a branch other than `master`.
2018-11-19 19:11:57 +00:00
"prepare": "npm run --silent check-no-prepare && npm-run-all install_all clean build || exit 0",
"prepublishOnly": "npm-run-all test check-working-tree",
"release": "node scripts/release.js",
"start": "run-p start:*",
"start:embark": "run-p start:embark:*",
"start:embark:babel": "npm run babel:watch",
"start:embark:type-check": "npm run type-check:watch",
"start:ui": "cd embark-ui && npm run start",
build: introduce a `prepare` script in embark's package.json **TL;DR** These changes affect workflow with yarn. To prevent embark's `prepare` script from running undesirably: - If node_modules is in place and you're reinstalling after switching branches: ``` yarn run install_all ``` - If node_modules is missing (fresh clone or deleted): ``` EMBARK_NO_PREPARE=t yarn install && yarn run install_all ``` It's not recommended to set `EMBARK_NO_PREPARE` in your environment (e.g. in `.bashrc`) since that would interfere with embark's `release` script if/when you run it. ----------------- **1.** Specify embark's build-related steps in the `prepare` script of package.json. When embark is installed directly from GitHub the `prepare` script results in a "pre install" phase (handled automatically by npm/yarn) that fetches devDependencies, builds embark (including embark-ui), packs a tarball with the same steps (minus testing and tree-checking) as would happen during an embark release, and finally does a production install from that tarball. Important point: installs from GitHub must be performed with yarn; they're no longer possible with npm since during the "pre install" phase npm will honor embark's `.npmrc` and `"engines"` settings. The following will work correctly after this commit is merged: ``` yarn [global] add git+https://github.com/embark-framework/embark.git ``` Use of "hosted git" shortcuts (e.g. `embark-framework/embark#bracnh`) won't work correctly because yarn doesn't fully support them. See: https://github.com/yarnpkg/yarn/issues/5235. It's important to use `git+https` urls. Following a succesful install with `git+https` it is possible to use a "hosted git" shortcut or `https` url, but that's owing to a subtle and unreliable interaction between yarn's cache and yarn's logic for installing from a url/shortcut. **2.** Adjust the npm configs (`.npmrc`) for embark/-ui so that `yarn run [cmd] [--opt]` can be used in place of `npm run [cmd] -- [--opt]`. Either way is okay for running scripts, they're equivalent, but note the requirement to use `--` before specifying command options with `npm run`. **3.** Introduce yarn configs (`.yarnrc`) for embark/-ui and include the `check-files` directive. H/t to @alaibe for the recommendation. **4.** Ignore embark's `dist/typings` and `scripts` directories when packing a tarball. **5.** Refactor embark/-ui's npm-scripts in relation to the `prepare` script, and make other small improvements. Notably, if the environment variable `EMBARK_NO_PREPARE` is truthy (from JS perspective) then embark's `prepare` script will exit early. This prevents `install_all` and `prepare` from getting stuck in a loop (`install:core` uses cross-env to set `EMBARK_NO_PREPARE`) and provides a mechanism for users to skip the `prepare` script when doing a fresh install: ``` EMBARK_NO_PREPARE=t yarn install ``` **6.** Give `.js` extensions to node scripts in embark's `scripts/`, remove the shebang lines, and have npm-scripts explicitly invoke them with node. This arrangement works for all platforms: Linux, macOS, and Windows. **7.** Adjust travis and appveyor configs. Since at present there aren't any tests or other CI steps that make use of embark-ui's production build, set `EMBARK_NO_PREPARE` in the CI environments and invoke `build:node` directly. Check the working tree after `yarn install` for embark/-ui. This detects situations where changes should have been committed to `yarn.lock` but were not. Check the working tree again at the end to detect situations where ignore files should have been adjusted but were not. Both checks could also detect other surprising behavior that needs to be investigated. Any time the working tree is not clean (there are untracked files or changes) CI will fail. Drop CI runs for node 8.11.3 because that version ships with an older npm that results in unstaged changes to the test apps' `package-lock.json` files, causing the working tree check to fail at the end of the CI run. A simple workaround isn't apparent, but the matter can be revisited. **8.** Refactor embark's `release` script in light of the `prepare` script. Notably, do the push step only after `npm publish` completes successfully. This allows embark's `prepare` and `prepublishOnly` scripts to detect problems before a commit and tag are pushed to GitHub, avoiding a need to rebase/revert the remote release branch; the local branch will still need to have a commit dropped and tag deleted before rerunning the `release` script. Prompt the user if the `release` script is not being run in `--dry-run` mode. Provide additional visual indicators of `--dry-run` mode. Force the user to supply `--repo-branch [branch]` if the intention is to release from a branch other than `master`.
2018-11-19 19:11:57 +00:00
"test": "npm-run-all lint test:*",
"test:core": "cross-env nyc --reporter=html mocha 'dist/test/**/*.js' --exit --no-timeouts --require source-map-support/register",
build: introduce a `prepare` script in embark's package.json **TL;DR** These changes affect workflow with yarn. To prevent embark's `prepare` script from running undesirably: - If node_modules is in place and you're reinstalling after switching branches: ``` yarn run install_all ``` - If node_modules is missing (fresh clone or deleted): ``` EMBARK_NO_PREPARE=t yarn install && yarn run install_all ``` It's not recommended to set `EMBARK_NO_PREPARE` in your environment (e.g. in `.bashrc`) since that would interfere with embark's `release` script if/when you run it. ----------------- **1.** Specify embark's build-related steps in the `prepare` script of package.json. When embark is installed directly from GitHub the `prepare` script results in a "pre install" phase (handled automatically by npm/yarn) that fetches devDependencies, builds embark (including embark-ui), packs a tarball with the same steps (minus testing and tree-checking) as would happen during an embark release, and finally does a production install from that tarball. Important point: installs from GitHub must be performed with yarn; they're no longer possible with npm since during the "pre install" phase npm will honor embark's `.npmrc` and `"engines"` settings. The following will work correctly after this commit is merged: ``` yarn [global] add git+https://github.com/embark-framework/embark.git ``` Use of "hosted git" shortcuts (e.g. `embark-framework/embark#bracnh`) won't work correctly because yarn doesn't fully support them. See: https://github.com/yarnpkg/yarn/issues/5235. It's important to use `git+https` urls. Following a succesful install with `git+https` it is possible to use a "hosted git" shortcut or `https` url, but that's owing to a subtle and unreliable interaction between yarn's cache and yarn's logic for installing from a url/shortcut. **2.** Adjust the npm configs (`.npmrc`) for embark/-ui so that `yarn run [cmd] [--opt]` can be used in place of `npm run [cmd] -- [--opt]`. Either way is okay for running scripts, they're equivalent, but note the requirement to use `--` before specifying command options with `npm run`. **3.** Introduce yarn configs (`.yarnrc`) for embark/-ui and include the `check-files` directive. H/t to @alaibe for the recommendation. **4.** Ignore embark's `dist/typings` and `scripts` directories when packing a tarball. **5.** Refactor embark/-ui's npm-scripts in relation to the `prepare` script, and make other small improvements. Notably, if the environment variable `EMBARK_NO_PREPARE` is truthy (from JS perspective) then embark's `prepare` script will exit early. This prevents `install_all` and `prepare` from getting stuck in a loop (`install:core` uses cross-env to set `EMBARK_NO_PREPARE`) and provides a mechanism for users to skip the `prepare` script when doing a fresh install: ``` EMBARK_NO_PREPARE=t yarn install ``` **6.** Give `.js` extensions to node scripts in embark's `scripts/`, remove the shebang lines, and have npm-scripts explicitly invoke them with node. This arrangement works for all platforms: Linux, macOS, and Windows. **7.** Adjust travis and appveyor configs. Since at present there aren't any tests or other CI steps that make use of embark-ui's production build, set `EMBARK_NO_PREPARE` in the CI environments and invoke `build:node` directly. Check the working tree after `yarn install` for embark/-ui. This detects situations where changes should have been committed to `yarn.lock` but were not. Check the working tree again at the end to detect situations where ignore files should have been adjusted but were not. Both checks could also detect other surprising behavior that needs to be investigated. Any time the working tree is not clean (there are untracked files or changes) CI will fail. Drop CI runs for node 8.11.3 because that version ships with an older npm that results in unstaged changes to the test apps' `package-lock.json` files, causing the working tree check to fail at the end of the CI run. A simple workaround isn't apparent, but the matter can be revisited. **8.** Refactor embark's `release` script in light of the `prepare` script. Notably, do the push step only after `npm publish` completes successfully. This allows embark's `prepare` and `prepublishOnly` scripts to detect problems before a commit and tag are pushed to GitHub, avoiding a need to rebase/revert the remote release branch; the local branch will still need to have a commit dropped and tag deleted before rerunning the `release` script. Prompt the user if the `release` script is not being run in `--dry-run` mode. Provide additional visual indicators of `--dry-run` mode. Force the user to supply `--repo-branch [branch]` if the intention is to release from a branch other than `master`.
2018-11-19 19:11:57 +00:00
"test:test_app": "cross-env DAPP=test_app npm run test_dapp",
"test:contracts_app": "cross-env DAPP=contracts_app npm run test_dapp",
"test_dapp": "cross-env-shell \"cd test_apps/$DAPP && npm install && npm test\"",
"tsc": "tsc",
"tslint": "tslint",
"type-check": "tsc",
"type-check:watch": "npm run type-check -- --watch"
2015-05-24 12:38:56 +00:00
},
"dependencies": {
2018-10-01 23:32:50 +00:00
"@babel/core": "7.1.2",
2018-10-01 23:33:32 +00:00
"@babel/plugin-proposal-class-properties": "7.1.0",
"@babel/plugin-proposal-decorators": "7.1.2",
2018-10-01 23:33:32 +00:00
"@babel/plugin-proposal-object-rest-spread": "7.0.0",
"@babel/plugin-syntax-dynamic-import": "7.0.0",
"@babel/plugin-transform-destructuring": "7.1.3",
2018-10-01 23:33:32 +00:00
"@babel/plugin-transform-flow-strip-types": "7.0.0",
2018-10-01 23:32:50 +00:00
"@babel/plugin-transform-runtime": "7.1.0",
"@babel/preset-env": "7.1.0",
"@babel/preset-react": "7.0.0",
2018-10-01 23:34:09 +00:00
"@babel/preset-typescript": "7.1.0",
2018-10-01 23:32:50 +00:00
"@babel/runtime-corejs2": "7.1.2",
"ajv": "6.5.5",
"ascii-table": "0.0.9",
"async": "2.6.1",
2018-10-01 23:32:50 +00:00
"babel-loader": "8.0.4",
2018-10-01 23:33:32 +00:00
"babel-plugin-macros": "2.4.2",
"babel-plugin-module-resolver": "3.1.1",
2018-10-01 23:33:32 +00:00
"babel-plugin-transform-react-remove-prop-types": "0.4.18",
"bip39": "2.5.0",
2018-10-17 20:21:23 +00:00
"body-parser": "1.18.3",
"check-dependencies": "1.1.0",
"chokidar": "2.0.4",
2018-10-13 00:46:53 +00:00
"clipboardy": "1.2.3",
"clone-deep": "4.0.0",
"colors": "1.3.2",
"commander": "2.18.0",
2018-10-01 23:32:50 +00:00
"css-loader": "1.0.0",
2018-10-03 21:23:23 +00:00
"date-and-time": "0.6.2",
"decompress": "4.2.0",
"deep-equal": "1.0.1",
"ejs": "2.6.1",
2018-12-07 23:40:28 +00:00
"embarkjs": "0.5.0",
"eth-ens-namehash": "2.0.8",
2018-11-13 13:58:30 +00:00
"ethereumjs-tx": "1.3.7",
"ethereumjs-util": "6.0.0",
"ethereumjs-wallet": "0.6.0",
"express": "4.16.3",
2019-01-09 14:22:57 +00:00
"express-http-proxy": "1.5.0",
"express-ws": "4.0.0",
2018-10-01 23:32:50 +00:00
"file-loader": "2.0.0",
2018-08-26 17:35:20 +00:00
"find-up": "2.1.0",
"flatted": "0.2.3",
"follow-redirects": "1.5.7",
"fs-extra": "7.0.0",
"fuzzy": "0.1.3",
"ganache-cli": "6.2.3",
"glob": "7.1.3",
"globule": "1.2.1",
2018-10-17 20:21:23 +00:00
"handlebars": "4.0.12",
2018-10-24 18:42:13 +00:00
"hard-source-webpack-plugin": "0.12.0",
"helmet": "3.13.0",
"hosted-git-info": "2.7.1",
"http-proxy": "1.17.0",
"http-shutdown": "1.2.0",
"i18n": "0.8.3",
2017-12-13 15:59:53 +00:00
"ipfs-api": "17.2.4",
"istanbul": "0.4.5",
2018-09-10 06:57:10 +00:00
"json-parse-better-errors": "1.0.2",
"live-plugin-manager-git-fix": "0.12.1",
"lodash.clonedeep": "4.5.0",
"merge": "1.2.0",
"mocha": "5.2.0",
"multihashes": "0.4.14",
"neo-blessed": "0.2.0",
"netcat": "1.3.5",
"node-http-proxy-json": "0.1.6",
"node-ipc": "9.1.1",
2018-10-02 00:15:44 +00:00
"node-sass": "4.9.3",
2018-08-08 00:45:35 +00:00
"npmlog": "4.1.2",
"opn": "5.3.0",
"ora": "2.1.0",
"os-locale": "2.1.0",
"parse-json": "4.0.0",
"pkg-up": "2.0.0",
"pretty-ms": "4.0.0",
"promptly": "2.2.0",
2017-12-19 18:29:48 +00:00
"propose": "0.0.5",
"pump": "3.0.0",
"remix-debug-debugtest": "0.2.16",
"remix-tests": "0.1.1",
"request": "2.88.0",
2018-10-02 00:15:44 +00:00
"sass-loader": "7.1.0",
2018-07-09 06:17:06 +00:00
"semver": "5.5.1",
"serve-static": "1.13.2",
"shelljs": "0.5.3",
"simples": "0.8.8",
2018-11-19 10:29:02 +00:00
"solc": "0.5.0",
"solidity-parser-antlr": "0.3.2",
"source-map-support": "0.5.9",
"stream-json": "1.1.3",
"string-replace-async": "1.2.1",
"style-loader": "0.23.1",
"swarm-api": "0.1.2",
"tar": "3.2.1",
"term.js": "0.0.7",
"url-loader": "1.1.2",
"uuid": "3.3.2",
"viz.js": "1.8.2",
feat(@embark/core): Run all code in VM2 All code to be run in the console is run through a completely sandboxed VM2 instance, instead of the default Node VM. VM2 will only allow whitelisted packages in a `require` statement. The whitelisted packages needed to run EmbarkJS scripts are: ``` [ "@babel/runtime-corejs2/helpers/interopRequireDefault", "@babel/runtime-corejs2/core-js/json/stringify", "@babel/runtime-corejs2/core-js/promise", "@babel/runtime-corejs2/core-js/object/assign", "eth-ens-namehash" ] ``` This can be circumvented in an Embark context (ie Plugin) if needed, for example in a Plugin constructor: ``` Embark.events.emit('runcode:register', 'require', require('lodash'), false); Embark.events.request("runcode:eval", "_.head(['a', 'b', 'c', 'd']);", (err, result) => { if(err) return console.log('========> error: ' + err); console.log('========> ' + result); }); ``` Will emit `========> a`. NOTE: Attempts to use this method to override `require` and `eval` should be handled by Embark and not allowed. NOTE: VM2 seems to allow `eval`, however it is in a completely sandboxed environment, so I'm unsure that we need to be too concerned with this. Thoughts? Refactor tests to use standalone instance of the newly created VM class, so that code is not evaluated through the console. This was done based on the new unit test case where accounts are redefined in a subsequent unit test, which was not originally working with the initial VM2 PR. Refactor `codeRunner`, put all code-affecting logic in the `VM` class. Changed `runCode` to `VM` and converted to TypeScript Add unit tests for `VM`.
2018-12-20 11:33:47 +00:00
"vm2": "3.6.4",
"web3": "1.0.0-beta.37",
"web3-bzz": "1.0.0-beta.37",
"web3-core": "1.0.0-beta.37",
"web3-core-helpers": "1.0.0-beta.37",
"web3-core-method": "1.0.0-beta.37",
"web3-core-promievent": "1.0.0-beta.37",
"web3-core-requestmanager": "1.0.0-beta.37",
"web3-core-subscriptions": "1.0.0-beta.37",
"web3-eth": "1.0.0-beta.37",
"web3-eth-abi": "1.0.0-beta.37",
"web3-eth-accounts": "1.0.0-beta.37",
"web3-eth-contract": "1.0.0-beta.37",
"web3-eth-iban": "1.0.0-beta.37",
"web3-eth-personal": "1.0.0-beta.37",
"web3-net": "1.0.0-beta.37",
"web3-providers-http": "1.0.0-beta.37",
"web3-providers-ipc": "1.0.0-beta.37",
"web3-providers-ws": "1.0.0-beta.37",
"web3-shh": "1.0.0-beta.37",
"web3-utils": "1.0.0-beta.37",
2018-10-01 23:32:50 +00:00
"webpack": "4.19.0",
"window-size": "1.1.1",
"ws": "6.1.2"
2015-05-24 12:38:56 +00:00
},
"devDependencies": {
"@babel/cli": "7.1.2",
"@babel/plugin-proposal-optional-chaining": "7.0.0",
"@types/async": "2.0.50",
2019-01-07 16:13:48 +00:00
"@types/body-parser": "1.17.0",
"@types/cors": "2.8.4",
"@types/express": "4.16.0",
2019-01-09 14:22:57 +00:00
"@types/express-http-proxy": "1.5.0",
2019-01-07 16:13:48 +00:00
"@types/express-ws": "3.0.0",
"@types/globule": "1.1.3",
"@types/handlebars": "4.0.39",
2019-01-07 16:13:48 +00:00
"@types/helmet": "0.0.42",
2018-11-16 12:49:09 +00:00
"@types/i18n": "0.8.3",
"@types/node": "10.11.7",
2018-11-16 12:49:09 +00:00
"@types/os-locale": "2.1.0",
2019-01-07 16:13:48 +00:00
"@types/pretty-ms": "3.2.0",
"@types/web3": "1.0.12",
"babel-plugin-dynamic-import-node": "2.2.0",
2018-09-21 21:41:53 +00:00
"chai": "4.1.2",
"chalk": "2.4.1",
2018-09-21 21:44:41 +00:00
"cross-env": "5.2.0",
2018-10-29 14:33:12 +00:00
"eslint": "5.7.0",
"eslint-plugin-react": "7.11.1",
"minimist": "1.2.0",
"mocha-sinon": "1.2.0",
"npm-run-all": "4.1.5",
2018-12-11 22:14:26 +00:00
"nyc": "13.1.0",
"rimraf": "2.6.2",
"sinon": "4.5.0",
"standard-version": "4.4.0",
"tslint": "5.11.0",
"typescript": "3.1.3"
},
"engines": {
"node": ">=8.11.3",
"npm": ">666",
"yarn": ">=1.12.3"
}
2015-05-24 12:38:56 +00:00
}