embark/packages/embark-vyper/package.json

68 lines
1.8 KiB
JSON
Raw Normal View History

{
"name": "embark-vyper",
"version": "4.0.0-beta.0",
"author": "Iuri Matias <iuri.matias@gmail.com>",
"contributors": [],
"description": "Embark is a framework that allows you to easily develop and deploy DApps",
"homepage": "https://embark.status.im/",
"keywords": [
"blockchain",
"dapps",
"ethereum",
"ipfs",
"serverless",
"solc",
"solidity"
],
"license": "MIT",
"repository": {
"directory": "packages/embark-vyper",
"type": "git",
"url": "https://github.com/embark-framework/embark.git"
},
"main": "./dist/index.js",
"files": [
"dist"
],
"scripts": {
"build": "cross-env BABEL_ENV=node babel src --extensions \".js,.ts\" --out-dir dist --root-mode upward --source-maps",
"ci": "npm run qa",
build: make DApp templates member packages of the monorepo Previously, templates were in a subdirectory of `packages/embark`. Reorganize them so that they are member packages of the monorepo. This allows them to cleanly depend on other members of the monorepo, e.g. `embarkjs-connector-web3`. It is desirable for the templates, in the context of the monorepo, to specify embark as a dependency, to take advantage of `npx embark test` (and it's a "forward looking" setup re: how we plan to evolve embark). However, if embark were to specify the template packages as dependencies a circular relationship would be introduced, which is [unsupported by Lerna][circular]. Therefore, revise the template generator so that all templates are resolved / fetched at runtime, i.e. `boilerplate`, `demo`, and `simple` are no longer "built-ins" *per se*. This change won't be apparent to embark's users, but it does mean that the template generator won't work (in a production install of embark) if it can't connect to the npm registry, i.e. when the user runs `embark demo` or `embark new [--simple]`. When embark is inside the monorepo, templates are resolved and copied from the yarn workspace rather than being fetched from the registry, which is convenient for development. Also, any template dependencies that are members of the monorepo are linked into the copied template's `node_modules` rather than being installed from the registry, again for convenience. During template generation, remove scripts and dependencies that pertain only to membership in the monorepo; for now, that involves removing embark as a dependency since we're not quite ready for that arrangement to be the default, i.e. outside of the monorepo. Refactor the root scripts so that more of them can consistently be used with Lerna's filter options, e.g. `--scope` and `--ignore`. "Combo" scripts that don't support filtering generally have a `:full` postfix. Flip `clean` and `reset` scripts at the root and in the member packages for consistency re: Lerna's notion of `clean` and embark's notion of `reset`. Have each package run its `reset` script when its `clean` script is invoked (and that's all for now), relying on `lerna clean` to delete packages' `node_modules` in view of how Lerna's topological sorting works. Lift the implementation of `embark reset` into a private package in `packages/embark-reset` and make it a bundled dependency of embark. Packages in `dapps/*` depend on `embark-reset` directly and make use of it with `npx embark-reset` (but only in monorepo context). This removes a "wart" where reboots could show errors when embark's sources aren't already built in `packages/embark/dist`. Users will not notice any difference since `embark reset` works as before, transparently making use of the `embark-reset` package. The only downside to having it be a bundled dependency of embark is that bundled deps have all of their `node_modules` included in the tarball built with `npm pack` (that's why having the templates as bundled dependencies of embark isn't a viable approach). However, `embark-reset` only has one dependency, `rimraf`, which is a tiny module, so the cost seems acceptable. As part of the reorganization, move `test_dapps` into `dapps/tests` and `packages/embark/templates` into `dapps/templates`. Keep the directory names short but revise the package names to facilitate simple filtering with `embark-dapp-*`. Consolidate `.yarnrc` and `.gitignore` and clean up some redundant ignore listings. Scripts run with `--scope embark-dapp-*` use `--concurrency=1` to avoid conflicts that could arise over network ports. The `ci:full` and `qa:full` scripts use `--concurrency=1` in all scopes, for two reasons: resource limitations on Travis and AppVeyor result in slower runs with concurrency >1, and if something fails in those contexts it's easier to see what went wrong when Lerna's output isn't interleaved from a bunch of scripts in `packages/*`. Bump the Lerna version. [circular]: https://github.com/lerna/lerna/issues/1198#issuecomment-442278902
2019-02-25 20:47:54 +00:00
"clean": "npm run reset",
"lint": "npm-run-all lint:*",
"lint:js": "eslint src/",
"lint:ts": "tslint -c tslint.json \"src/**/*.ts\"",
"package": "npm pack",
"// qa": "npm-run-all lint typecheck build package",
"qa": "npm-run-all lint build package",
build: make DApp templates member packages of the monorepo Previously, templates were in a subdirectory of `packages/embark`. Reorganize them so that they are member packages of the monorepo. This allows them to cleanly depend on other members of the monorepo, e.g. `embarkjs-connector-web3`. It is desirable for the templates, in the context of the monorepo, to specify embark as a dependency, to take advantage of `npx embark test` (and it's a "forward looking" setup re: how we plan to evolve embark). However, if embark were to specify the template packages as dependencies a circular relationship would be introduced, which is [unsupported by Lerna][circular]. Therefore, revise the template generator so that all templates are resolved / fetched at runtime, i.e. `boilerplate`, `demo`, and `simple` are no longer "built-ins" *per se*. This change won't be apparent to embark's users, but it does mean that the template generator won't work (in a production install of embark) if it can't connect to the npm registry, i.e. when the user runs `embark demo` or `embark new [--simple]`. When embark is inside the monorepo, templates are resolved and copied from the yarn workspace rather than being fetched from the registry, which is convenient for development. Also, any template dependencies that are members of the monorepo are linked into the copied template's `node_modules` rather than being installed from the registry, again for convenience. During template generation, remove scripts and dependencies that pertain only to membership in the monorepo; for now, that involves removing embark as a dependency since we're not quite ready for that arrangement to be the default, i.e. outside of the monorepo. Refactor the root scripts so that more of them can consistently be used with Lerna's filter options, e.g. `--scope` and `--ignore`. "Combo" scripts that don't support filtering generally have a `:full` postfix. Flip `clean` and `reset` scripts at the root and in the member packages for consistency re: Lerna's notion of `clean` and embark's notion of `reset`. Have each package run its `reset` script when its `clean` script is invoked (and that's all for now), relying on `lerna clean` to delete packages' `node_modules` in view of how Lerna's topological sorting works. Lift the implementation of `embark reset` into a private package in `packages/embark-reset` and make it a bundled dependency of embark. Packages in `dapps/*` depend on `embark-reset` directly and make use of it with `npx embark-reset` (but only in monorepo context). This removes a "wart" where reboots could show errors when embark's sources aren't already built in `packages/embark/dist`. Users will not notice any difference since `embark reset` works as before, transparently making use of the `embark-reset` package. The only downside to having it be a bundled dependency of embark is that bundled deps have all of their `node_modules` included in the tarball built with `npm pack` (that's why having the templates as bundled dependencies of embark isn't a viable approach). However, `embark-reset` only has one dependency, `rimraf`, which is a tiny module, so the cost seems acceptable. As part of the reorganization, move `test_dapps` into `dapps/tests` and `packages/embark/templates` into `dapps/templates`. Keep the directory names short but revise the package names to facilitate simple filtering with `embark-dapp-*`. Consolidate `.yarnrc` and `.gitignore` and clean up some redundant ignore listings. Scripts run with `--scope embark-dapp-*` use `--concurrency=1` to avoid conflicts that could arise over network ports. The `ci:full` and `qa:full` scripts use `--concurrency=1` in all scopes, for two reasons: resource limitations on Travis and AppVeyor result in slower runs with concurrency >1, and if something fails in those contexts it's easier to see what went wrong when Lerna's output isn't interleaved from a bunch of scripts in `packages/*`. Bump the Lerna version. [circular]: https://github.com/lerna/lerna/issues/1198#issuecomment-442278902
2019-02-25 20:47:54 +00:00
"reset": "npx rimraf dist embark-*.tgz package",
"start": "npm run watch",
"// typecheck": "tsc",
"watch": "run-p watch:*",
"watch:build": "npm run build -- --verbose --watch",
"// watch:typecheck": "npm run typecheck -- --preserveWatchOutput --watch"
},
"eslintConfig": {
"extends": "../../.eslintrc.json"
},
"dependencies": {
"@babel/runtime-corejs2": "7.3.1",
2019-02-07 10:59:56 +00:00
"embark-async-wrapper": "4.0.0-beta.0",
"shelljs": "0.5.3"
},
"devDependencies": {
"@babel/cli": "7.2.3",
"@babel/core": "7.2.2",
"cross-env": "5.2.0",
"eslint": "5.7.0",
"npm-run-all": "4.1.5",
"rimraf": "2.6.3",
"tslint": "5.11.0",
"typescript": "3.3.1"
},
"engines": {
"node": ">=8.12.0",
"npm": ">=6.4.1",
"yarn": ">=1.12.3"
}
}