Analysis of Broccoli

broccoli

# Strengths
- No leftover files
  - Solved by passing temporary directories between plugins (i.e. tasks)

# Weaknesses
- No parallel plugin execution
  - No parallel tasks: Independent tasks could execute in parallel
  - No parallel builds: Can't decouple independent parts, e.g. unit tests from rest

- Code base issues
  - Too decentralized: Some mechanisms like merge and pick should be in core. They cannot be used standalone anyway. Others: quick-temp, writer, filter, helpers
  - broccoli-cli should be its own package and cli, server and middleware should be part of it

- i/o problems
  - symlinking should be used inside the tmp/ directory (There is no bug if only directories inside tmp/ are symlinked)
  - Too much file walking: File structure in tmp/ directory sould be kept partly in RAM

- Tasks instances don't get assotiated with a broccoli builder instances
  - Consequence: No proper sharing of state, like for tmp dir, cwd and other configs

- No inheritance: Plugins don't inherit from a common super class
  - No convenience methods
    - Ugly: `readTree` function has to be passed in as an argument
  - No default behaviour

- Cannot visualize build pipeline

- Sync code everywhere: Blocked event loop problems (e.g. broken progress indicator in ember-cli)

- No logging system: Plugins should have a standardized way to post log messages (for JSHint, and other plugins which should create non-error messages). build() should return a promise with a logs object, build time etc.

Note: I removed "No source mapping solution" because it's up to the plugins. This point cannot be considered a flaw of the build system itself.