Build improvements

[tom-odb]

During development of other monorepo setups some improvements were made that could be beneficial here as well. In this issue, I'll point out some flaws and areas that could be improved in the current setup and propose a solution for each one.

Custom scripts

Overall: some cleanup is required, might be an idea to move these tools to a custom cli package to remove some of the more trivial things from this repo.

We should use the built-in tooling as much as possible, and attempt to extend following angular-cli conventions (e.g. writing custom builders).

Build script

There are currently only 2 options when building:

1. build 1 package
2. build all packages

When building 1 package, the assumption is made that its dependencies are already built. When building all packages, dependencies are evaluated to build the packages in the right order.

Ideally, an option would be added to do the same when building 1 package.

Watch

Currently, there is no watch mode. This could be easily added using chokidar or built-in angular-cli tools.

Testing

Jest should be looked at as a valid alternative for the current karma+jasmine combo. The pattern matching allows developers to easily target the tests they are working on. Runtime in ci should improve as well.

Note: There are some options to integrate Jest with the angular-cli. The most promising one (imo) is this custom builder, allowing you to run jest with ng test.

There are some caveats though (besides support), the biggest one being an error that is thrown for each suite when running all tests. The tests do succeed but this creates an odd side effect to contributors.

Dependencies

Individual packages should not have their own dependencies. The current setup allows each package to define its dependencies, extracts them all to the root and attempts to resolve all conflicting versions with a custom script.

Following angular-cli conventions, all dependencies should be defined in the root, avoiding conflicts with locally installed packages.

Barrel files

Barrel files are a pain and should be avoided as much as possible, especially when working with TypeScript.

To resolve any issues, we should avoid using them altogether. Within 1 package all imports should be as specific as possible. To avoid having the module files grow exponentially, a file can be added in the root of each folder to aggregate the present types.

An example:

packages
|_ user
    |_ components
       |_ avatar
       |   |_ avatar.component.ts
       |_ profile
       |   |_ profile.component.ts
       |_ components.ts

// components.ts
import { AvatarComponent } from './avatar/avatar.component';
import { ProfileComponent } from './profile/profile.component';

export const UserComponents = [
  AvatarComponent,
  ProfileComponent,
];

export const UserEntryComponents = [
  AvatarComponent,
];

public_api.ts

The only barrel(-ish) file should be the public_api (following angular-cli naming conventions). Ideally, this is auto-generated, solving two issues simultaneously:

1. developers no longer have to manually update the file
2. everything present in the package is exported, avoiding auto exports and potentially conflicting variable names

I set up a package to do just that: https://github.com/tom-odb/named-exports. Feel free to integrate/extend/copy-paste this into the acpaas-ui tooling.

Examples

The way the examples are currently set up is not manageable in the long term. Building a single example is impossible and actively developing in the styleguide is impractical and frustrating.

Proposition:

• separate the examples from the packages
• remove all custom scripting

tldr

1. custom scripts should be cleaned up, extended and moved to a custom tools (cli) package
2. tests should be run with Jest
3. dependencies should be moved to the root and only exist there
4. barrel files should be killed (with fire) and public_api's should be auto-generated
5. writing new examples is nearly impossible