Add cli build checks, and circular dep check for types lib

[mnaamani]

Adding CI checks for types and cli packages

[Lezek123]

As discussed in the chat: it would probably be a good idea to include MacOS builds too (like it's already done for Pioneer), since with different filesystem etc. there may be some issues that will be undetected on Ubuntu.

[mnaamani]

As discussed in the chat: it would probably be a good idea to include MacOS builds too (like it's already done for Pioneer), since with different filesystem etc. there may be some issues that will be undetected on Ubuntu.

Agreed. Added in 79a87d8

I also increased the TCP network timeout for OSX jobs to try to resolve the frequent issue with installing packages due to unstable network connections on the mac instances. 2067c50

[Lezek123]

I noticed that since building @joystream/types is part of the yarn postInstall script, any build error in @joystream/types will actually cause all the checks to fail (Lezek123#7). This means that build checks for @joystream/types itself may currently be unnecessary and we also don't need to run yarn workspace @joystream/types build before the CLI build check. Perhaps we can add a circular dependency check instead for the types (with madge --circular types right after yarn install)?

The CLI build check seems to work fine, I was even able to produce an error that causes the build to fail only on Mac ( Lezek123#8)

Didn't run into any issues regarding network connection during Mac builds, so hopefully it's now fixed.

[mnaamani]

Great feedback.
Will drop the jobs exlusively for types and add the circular check as suggested.

[Lezek123]

Looks good.
The circular dependencies are correctly spotted etc.
It doesn't seem necessary to do the circular dependency check in each job, but since @joystream/types are beeing built in each job too, it seems kind of logical (and this way we also avoid having too many serparate checks).

[mnaamani]

After working on #785 I identified a useful check we can add for the types library which I can do in a future PR. Basically to ensure that the module can be published to npm and installed successfully buy using npm pack to test it locally.