Ethan Frey

Current result of `yarn install --prod` yields 157 packages in node_modules. (Maybe more, I think we need `--flat` as well to really show them all). A quick glance shows some...

Good point... I think we need to publish the root yarn.lock to npm for every package. It may be a superset of what is needed, but will only constrain what...

> Convert Ganache CLI installation from npm to docker (removed 1/3 of all deps #625) > Implement Ethereum support with only 1 external dependency (https://github.com/iov-one/iov-core/blob/v0.10.2/packages/iov-ethereum/package.json#L33) :+1:

> The problem with the packages mentioned above is: we don't import them directly. Those are transient dependencies introduced by other maintainers and as long there is nothing seriously wrong...

Sounds like a good plan. Only needed for dev dependencies. But maybe outsourced to a script/docker image

> However, implementing this is too complicated as long as one identity can be in a profile multiple times Yes, I would love to enforce uniqueness and then remove need...

I think this does not belong in iov-core itself, but rather tooling (like we have for deployment), so we can make use of tons of libraries without adding all those...

Apparently this is a known and open issue in ts-node: https://github.com/TypeStrong/ts-node/issues/8 There is a fork that produces something very nice (eg `:type Buffer` scroll to the bottom of the readme),...

Just discovered this tidbit in ts-node ``` > .type profile const profile: UserProfile > .type profile.getIdentities (method) UserProfile.getIdentities(n: number): ReadonlyArray ```

If you are smart, you can make it 0. Especially if such "smart" usage can trigger un-tested edge case -> possible exploit. I mean, sending wei to another account has...