There's a lot of cruft here. Consider that while a project might have a prominently named file like "README" that is meant to be the first thing a wanderer encounters, the true first encounter is the file listing in the project source tree:

• build/
• config/
• src/
• .babelrc
• .dockerignore
• .editorconfig
• .gitignore
• .stylelintrc
• .travis.yml
• Dockerfile
• Gruntfile.js
• LICENSE
• Procfile
• README.md
• aldine.sublime-project
• aldine.sublime-workspace
• circle.yml
• package.json
• tsconfig.json
• tslint.json
• yarn.lock

Imagine a commit (or a pull request) with the summary "Remove cruft". Why might it be rejected? Let's get more specific.

There's a Dockerfile here. There's also a package.json. We can ask of each of these, "Why is this here?" The answer is, "Because someone found them useful." Consider, then, that here's a strong case for a contrib/ directory† for this project and where these things should be kept, ill-conceived tooling conventions notwithstanding.

† This link points to a particular blog post that explains the purpose of a contrib/ directory, but this is not an endorsement of Mr DeVault's other positions or demeanor. Ignore any stridence, arrogance, or other obnoxiousness that you might encounter in your pursuit to pull at any threads from that corner of the Web.

Running the tests should be as easy as opening something in the browser.

I've done absolutely no actual work in this part, but this is what the third part (the C) in the "ABCs of triple scripts" is supposed to be about.