#!/bin/bash
set -e  # Exit on non-zero status
set -u  # Treat unset variables as an error

# Why is this not using docker-compose??
# Short answer; because it doesn't need to and it doesn't work otherwise.
#
# Long answer; Inside the docker container, we install yarn packages into
# /tools/node_modules. For some executable tools you can then tell them
# that node_modules is NOT in `.`. You can do that with flow too, by
# setting a config in .flowconfig. But if you do that, you make it impossible
# to use `./node_modules` if you run your own flow on your host laptop.
# And that's a use case we don't want to lose because it's so much
# faster than running it inside docker. Especially when run repeatedly.
# This file primarily exists for the benefit of continuous integration
# (aka. TravisCI) and TravisCI will already install node_modules twice.
# Once, automatically because there's a `package.json` in the project
# root and once based on the instructions in kuma_base/Dockerfile.
# Last but not least, Flow has much less effect on the runtime of the
# JavaScript code. So it's OK to run it outside the specified Node version
# as per the Dockerfile(s).
flow