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

29 lines
759 B
JSON
Raw Normal View History

feat(@embark/utils): "inside monorepo" APIs
2019-09-16 20:39:22 +00:00
{
"name": "embark-inside-monorepo",
"private": true,
chore(release): 5.2.3
2020-02-25 21:09:29 +00:00
"version": "5.2.3",
feat(@embark/utils): "inside monorepo" APIs
2019-09-16 20:39:22 +00:00
"author": "Michael Bradley <michaelsbradleyjr@gmail.com> (https://github.com/michaelsbradleyjr/)",
"description": "If a package from the monorepo can resolve this package then the first package is inside the monorepo",
"license": "MIT",
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": "./src/index.js",
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 17:01:38 +00:00
"scripts": {
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
"ci": "npm run qa",
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 17:01:38 +00:00
"clean": "npm run reset",
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": "eslint src/",
"qa": "npm-run-all lint",
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 17:01:38 +00:00
"reset": "npx rimraf embark-*.tgz package"
},
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"
},
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 17:01:38 +00:00
"devDependencies": {
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: 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 17:01:38 +00:00
"rimraf": "3.0.0"
},
build: tidy up the monorepo in prep for v5.0.0-alpha.0
2019-09-27 17:58:08 +00:00
"engines": {
feat: support Node.js v12.x and newer Remove the `<12.0.0` restriction re: Node.js version in the `"engines"` settings for all the packages in the monorepo that had that restriction. Add missing `"engines"` settings in `packages/plugins/snark/package.json`. Adjust the Azure Pipelines config to include builds for Node.js v12.x and v13.x. Bump `solc` to `0.4.26` in `dapps/tests/app` and `dapps/tests/contracts`. It was discovered that older versions suffered a fatal `Maximum call stack size exceeded` error when run on Windows with Node.js v12.x or newer. Display a warning re: the bad combo (solc version + Windows + Node version) if it's detected at runtime. Adjust the root `yarn.lock` so that the `sha3` transitive dependency resolves to a newer version that is compatible with Node v13.x.
2020-01-17 17:32:32 +00:00
"node": ">=10.17.0",
build: bump all packages' engines settings (#1985) BREAKING CHANGE: node: >=10.17.0 <12.0.0 npm: >=6.11.3 yarn: >=1.19.1 node v10.17.0 is the latest in the 10.x series and is still in the Active LTS lifecycle. Embark is still not compatible with node's 12.x and 13.x series (because of some dependencies), otherwise it would probably make sense to bump our minimum supported node version all the way to the most recent 12.x release. npm v6.11.3 is the version that's bundled with node v10.17.0. yarn v1.19.1 is the most recent version as of the time node v10.17.0 was released.
2019-10-24 13:52:05 +00:00
"npm": ">=6.11.3",
"yarn": ">=1.19.1"
build: tidy up the monorepo in prep for v5.0.0-alpha.0
2019-09-27 17:58:08 +00:00
}
feat(@embark/utils): "inside monorepo" APIs
2019-09-16 20:39:22 +00:00
}