embarklabs
/
embark
mirror of https://github.com/embarklabs/embark.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
embark/packages/plugins/ens
History
Michael Bradley, Jr ee56f37713 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-13 13:59:47 -05:00
..
src fix(@cockpit/ens): ensure default account is set when registering subdomains 2019-12-11 11:30:58 -05:00
test build: specify missing test action in relevant package.json "qa" scripts 2019-12-11 14:01:12 -06:00
.npmrc move embarkjs packages & remove embark- prefix from some folders (#1879) 2019-09-06 18:26:08 -04:00
CHANGELOG.md chore(release): 5.0.0-alpha.4 2019-12-12 11:38:22 -05:00
README.md build: tidy up the monorepo in prep for v5.0.0-alpha.0 2019-10-01 13:29:53 -05:00
package.json build: implement collective typecheck 2019-12-13 13:59:47 -05:00
tsconfig.json build: implement collective typecheck 2019-12-13 13:59:47 -05:00

README.md

embark-ens

Implements ENS support in Embark

This module:

  • registers console commands to interact with ENS
  • deploys & setups ENS contracts depending on the network
  • implements ENS support in EmbarkJS
  • setups generated code acording to the config

API

command: ens:resolve - returns the address of an ens name

arguments:

  • name - ens name to resolve

response:

  • error - if an error occurs, null otherwise
  • address - address associated to the ens name given

command: ens:isENSName - checks is it's a (valid) ENS name

arguments:

  • name - ens name to validate

response:

  • error - if an error occurs, null otherwise
  • result - true/false depending if name given is a valid ens name

command: storage:ens:associate - associates an hash to an ENS domain

arguments:

  • options
    • name - ens name
    • storageHash - hash to associate

response:

  • error - if an error occurs, null otherwise

Web API

endpoint: GET /embark-api/ens/resolve - returns the address of an ens name

arguments:

  • name - ens name to resolve

response:

{
  address: <address of ens name>
}

endpoint: GET /embark-api/ens/lookup - returns the ens name of an address

arguments:

  • address - address to query

response:

{
  name: <ens name of address>
}

endpoint: POST /embark-api/ens/register registers a domain or subdomain

arguments:

  • subdomain - ens domain
  • address - address to associate

response:

{
  name: <ens name>
  address: <address>
}

Dependencies

  • async
  • eth-ens-namehash
  • embarkjs.utils
    • secureSend
  • embark utils
    • AddressUtils
    • hashTo32ByteHexString
    • recursiveMerge