embarklabs/embark
2
0
Fork 0
mirror of https://github.com/embarklabs/embark.git synced 2025-02-04 01:44:24 +00:00
Code Issues Projects Releases Wiki Activity
embark/dapps/tests/contracts/package.json

26 lines
653 B
JSON
Raw Normal View History

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 14:47:54 -06:00
{
feat: normalize README and package.json bugs, homepage, description Make changes by running these commands in the root of the monorepo: **bugs** ```shell npx lerna exec --concurrency 1 --stream -- \ 'DIRPATH=$(realpath $PWD --relative-to=$LERNA_ROOT_PATH); \ npx json -I -f package.json -e "this.bugs=\ \"https://github.com/embark-framework/embark/issues\""' ``` **homepage** ```shell npx lerna exec --concurrency 1 --stream -- \ 'DIRPATH=$(realpath $PWD --relative-to=$LERNA_ROOT_PATH); \ npx json -I -f package.json -e "this.homepage=\ \"https://github.com/embark-framework/embark/tree/master/${DIRPATH}#readme\""' ``` Don't commit changes to private packages, with the exceptions of embark-typings and embark-reset because those may switch from private to public, and also because the latter will be included in `node_modules` of embark even if it is private since embark-reset is presently a bundled dependency of embark. Don't include the homepage and bugs fields in dapps generated from the template packages, except for the demo. Set those dapps' description field to an empty string. Ensure every package (inc. private packages) has a description. Ensure every package (inc. private packages) has a README that begins with: ```markdown `[pkgJson.name]` ================ > [pkgJson.description] Visit [embark.status.im](https://embark.status.im/) to get started with [Embark](https://github.com/embark-framework/embark). ``` Don't include the README in dapps generated from the template packages, except for the demo.
2019-03-08 13:58:27 -06:00
"description": "Test DApp for integration testing purposes",
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 14:47:54 -06:00
"devDependencies": {
chore(release): 5.0.0
2020-01-07 12:14:37 -06:00
"embark": "^5.0.0",
"embark-reset": "^5.0.0",
"embarkjs": "^5.0.0",
"embarkjs-ens": "^5.0.0",
"embarkjs-ipfs": "^5.0.0",
"embarkjs-swarm": "^5.0.0",
"embarkjs-web3": "^5.0.0",
"embarkjs-whisper": "^5.0.0",
build: implement collective typecheck This PR replaces #2057. Implement a collective typecheck action that can be invoked in the root of the monorepo with `yarn typecheck` or in watch-mode with `yarn watch:typecheck`. Include the watch-mode typecheck action as part of `yarn start` (a.k.a `yarn watch`). To activate collective typecheck for a package in the monorepo, its `package.json` file should specify: ``` { "embark-collective": { "typecheck": true } } ``` *-or-* ``` { "embark-collective": { "typecheck": {...} } } ``` Where `{...}` above is a `tsconfig.json` fragment that will be merged into the config generated for the package according the same rules that `tsc` applies when merging [configs][config]. When collective typecheck begins, it generates a `tsconfig.json` for the root of the monorepo and for each package that is activated for the action. If the generated JSON is different than what's on disk for the respective root/package config, or if the config is not present on disk, then it will be written. Changes to generated `tsconfig.json` files should be committed; such changes will arise when there are structural changes to the monorepo, e.g. a package is added, removed, moved and/or the directory containing it is renamed. Since the configs are only generated at the beginning of collective typecheck, when structural changes are made in the monorepo `yarn typecheck` (or `yarn start` or `yarn watch:typecheck`) should be restarted. Nearly all of the packages in the monorepo (i.e. all those for which it makes sense) have been activated for collective typecheck. Even those packages that don't contain `.ts` sources are activated because `tsc` can make better sense of the code base as a whole owing to the project references included in the generated `tsconfig.json` files. Also, owing to the fully cross-referenced `tsconfig.json` files, it's possible for `tsc` to type check the whole code base without babel (`yarn build` or `yarn watch:build`) having been run beforehand. **NOTE** that a *"cold typecheck"* of the whole monorepo is resource intensive: on this author's 2019 MacBook Pro it takes around three minutes, the fans spin up, and `tsc` uses nearly 0.5 GB of RAM. However, once a full typecheck has completed, the next full typecheck will complete in a few seconds or less; and when running in watch-mode there is likewise a *big* speedup once a full typecheck has completed, whether that full check happened before it's running in watch-mode or when watch-mode itself resulted in a full check before switching automatically to incremental check, as well a corresponding *big* reduction in resource consumption. A full check will be needed any time `yarn typecheck` (or `yarn start` or `yarn watch:typecheck`) is run in a fresh clone plus `yarn install`, or after doing `yarn reboot[:full]` or `yarn reset`. The combination of options in each generated package-level `tsconfig.json` and the root `tsconfig.base.json` result in `tsc` writing `.d.ts` files (TypeScript declaration files) into the `dist/` directory of each package. That output is intended to live side-by-side with babel's output, and therefore the `"rootDir"` option in each generated config is set to `"./src"`. In projects activated for collective typecheck, `.js` may be converted to `.ts` and/or `.ts` sources may be added without any additional changes needed in package-level `package.json`. --- Reorganize types in `packages/core/typings` (a.k.a `@types/embark`) into `packages/core/core` (`embark-core`), refactor other packages' imports accordingly, and delete `packages/core/typings` from the monorepo. This results in some similarly named but incompatible types exported from `embark-core` (e.g. `Events` and `EmbarkEvents`, the latter being the one from `packages/core/typings`); future refactoring should consolidate those types. To avoid circular dependency relationships it's also necessary to split out `Engine` from `embark-core` into its own package (`embark-engine`) and to introduce a bit of duplication, e.g. the `Maybe` type that's now defined in both `embark-i18n` and `embark-core`. In the process of the types reorg, move many dependencies spec'd in various `package.json` to the `package.json` of the package/s that actually depend on them, e.g. many are moved from `packages/embark/package.json` to `packages/core/engine/package.json`. Related to those moves, fix some Node.js `require`-logic related to bug-prone dependency resolution. Fix all type errors that appeared as a result of activating collective typecheck across the whole monorepo. Reactivate `tslint` in `packages/core/core` and fix the remaining linter errors. Tidy up and add a few items in the root `package.json` scripts. Bump lerna from `3.16.4` to `3.19.0`. Bumpt typescript from `3.6.3` to `3.7.2`. Bumpt tslint from `5.16.0` to `5.20.1`. Make various changes related to packages' `import`/`require`ing packages that weren't spec'd in their respective `package.json`. More refactoring is needed in this regard, but changes were made as the problems were observed in the process of authoring this PR. [config]: https://www.typescriptlang.org/docs/handbook/tsconfig-json.html
2019-12-11 11:01:38 -06:00
"rimraf": "3.0.0"
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 14:47:54 -06:00
},
build: tidy up the monorepo in prep for v5.0.0-alpha.0
2019-09-27 12:58:08 -05:00
"license": "MIT",
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 14:47:54 -06:00
"name": "embark-dapp-test-contracts",
"private": true,
"scripts": {
"ci": "npm run qa",
"clean": "npm run reset",
"qa": "npm run test",
build: implement collective typecheck This PR replaces #2057. Implement a collective typecheck action that can be invoked in the root of the monorepo with `yarn typecheck` or in watch-mode with `yarn watch:typecheck`. Include the watch-mode typecheck action as part of `yarn start` (a.k.a `yarn watch`). To activate collective typecheck for a package in the monorepo, its `package.json` file should specify: ``` { "embark-collective": { "typecheck": true } } ``` *-or-* ``` { "embark-collective": { "typecheck": {...} } } ``` Where `{...}` above is a `tsconfig.json` fragment that will be merged into the config generated for the package according the same rules that `tsc` applies when merging [configs][config]. When collective typecheck begins, it generates a `tsconfig.json` for the root of the monorepo and for each package that is activated for the action. If the generated JSON is different than what's on disk for the respective root/package config, or if the config is not present on disk, then it will be written. Changes to generated `tsconfig.json` files should be committed; such changes will arise when there are structural changes to the monorepo, e.g. a package is added, removed, moved and/or the directory containing it is renamed. Since the configs are only generated at the beginning of collective typecheck, when structural changes are made in the monorepo `yarn typecheck` (or `yarn start` or `yarn watch:typecheck`) should be restarted. Nearly all of the packages in the monorepo (i.e. all those for which it makes sense) have been activated for collective typecheck. Even those packages that don't contain `.ts` sources are activated because `tsc` can make better sense of the code base as a whole owing to the project references included in the generated `tsconfig.json` files. Also, owing to the fully cross-referenced `tsconfig.json` files, it's possible for `tsc` to type check the whole code base without babel (`yarn build` or `yarn watch:build`) having been run beforehand. **NOTE** that a *"cold typecheck"* of the whole monorepo is resource intensive: on this author's 2019 MacBook Pro it takes around three minutes, the fans spin up, and `tsc` uses nearly 0.5 GB of RAM. However, once a full typecheck has completed, the next full typecheck will complete in a few seconds or less; and when running in watch-mode there is likewise a *big* speedup once a full typecheck has completed, whether that full check happened before it's running in watch-mode or when watch-mode itself resulted in a full check before switching automatically to incremental check, as well a corresponding *big* reduction in resource consumption. A full check will be needed any time `yarn typecheck` (or `yarn start` or `yarn watch:typecheck`) is run in a fresh clone plus `yarn install`, or after doing `yarn reboot[:full]` or `yarn reset`. The combination of options in each generated package-level `tsconfig.json` and the root `tsconfig.base.json` result in `tsc` writing `.d.ts` files (TypeScript declaration files) into the `dist/` directory of each package. That output is intended to live side-by-side with babel's output, and therefore the `"rootDir"` option in each generated config is set to `"./src"`. In projects activated for collective typecheck, `.js` may be converted to `.ts` and/or `.ts` sources may be added without any additional changes needed in package-level `package.json`. --- Reorganize types in `packages/core/typings` (a.k.a `@types/embark`) into `packages/core/core` (`embark-core`), refactor other packages' imports accordingly, and delete `packages/core/typings` from the monorepo. This results in some similarly named but incompatible types exported from `embark-core` (e.g. `Events` and `EmbarkEvents`, the latter being the one from `packages/core/typings`); future refactoring should consolidate those types. To avoid circular dependency relationships it's also necessary to split out `Engine` from `embark-core` into its own package (`embark-engine`) and to introduce a bit of duplication, e.g. the `Maybe` type that's now defined in both `embark-i18n` and `embark-core`. In the process of the types reorg, move many dependencies spec'd in various `package.json` to the `package.json` of the package/s that actually depend on them, e.g. many are moved from `packages/embark/package.json` to `packages/core/engine/package.json`. Related to those moves, fix some Node.js `require`-logic related to bug-prone dependency resolution. Fix all type errors that appeared as a result of activating collective typecheck across the whole monorepo. Reactivate `tslint` in `packages/core/core` and fix the remaining linter errors. Tidy up and add a few items in the root `package.json` scripts. Bump lerna from `3.16.4` to `3.19.0`. Bumpt typescript from `3.6.3` to `3.7.2`. Bumpt tslint from `5.16.0` to `5.20.1`. Make various changes related to packages' `import`/`require`ing packages that weren't spec'd in their respective `package.json`. More refactoring is needed in this regard, but changes were made as the problems were observed in the process of authoring this PR. [config]: https://www.typescriptlang.org/docs/handbook/tsconfig-json.html
2019-12-11 11:01:38 -06:00
"reset": "npx embark-reset && npx rimraf embark-*.tgz 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 14:47:54 -06:00
"test": "npx embark test"
},
chore(release): 5.0.0
2020-01-07 12:14:37 -06:00
"version": "5.0.0"
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 14:47:54 -06:00
}
Reference in New Issue Copy Permalink