Research solution for adding a new deployable React package to the Civic monorepo

[MikeTheCanuck]

Project teams at some point will want to know how they can get their React application deployed to AWS.

We need to make sure we have a well-understood procedure to add a new React package to our existing Civic monorepo. This will have to be performed at least once for each of the five project teams, and it would be reasonable to expect to have to perform this task again afterwards for special cases or evolving HackOregon needs.

Assume that:

• project team has a React application that successfully launches from the results of npm run build
• project team can clearly spell out where the deployable assets can be found (e.g. /build)
• project team can clearly articulate any and all dependencies they have taken from other civic monorepo packages, and that they're sticking with the existing versions
• React app is working with functioning APIs in the cloud (so it can be tested in Travis)
• React app starts out resembling the React apps from the 2017 project season (so that whatever solution we work out for CI/CD based on the existing apps will mostly work for the new apps)
• we will use the same S3 bucket architecture for deploying additional React apps as we're using for the 2017 apps
• Travis web environment configuration will be managed by the DevOps team

Requirements

Here are my initial thoughts on what is required to successfully provide the "new React app" service:

• documented prerequisites - what information do we need, and steps they must take, for us to be able to successfully deploy a new React app to AWS
• documentation outlining the steps DevOps squad takes to build, test and deploy the proposed API
• thoughts on how to communicate the successful result, including how to obtain the IP address of the new app
• templates for initializing a new React app in the HackOregon monorepo (e.g. standard package.json scripts)
• (optional) Travis configuration that builds, tests and deploys a single package as public files to S3

The steps in this procedure should ultimately be documented so that any project team can understand their prerequisites and what happens once their "new React app" request is initiated. Let's hack some initial docs up quickly, and use our first couple of rounds of the actual fulfilment to refine the docs.

Questions:

• are we required to support apps initialized from Create-React-App on day one?

[MikeTheCanuck]

What/why/how a Monorepo:
https://github.com/babel/babel/blob/master/doc/design/monorepo.md
https://lernajs.io/

Possible issues to dig into:
schibsted/eslint-config-schibsted#46

[MikeTheCanuck]

Status:

• confirmed that the civic monorepo is still building, testing and starting the 2017 project packages successfully
• unable to find a continuous deployment pattern for pushing new builds of projects to their respective S3 bucket
• also discovered that CRA (create-react-app) aborts when creating a new package in the civic/packages directory - but the same CRA succeeds when creating a standalone React app

[MikeTheCanuck]

Tested:

• create a new React app with CRA in a standalone folder, mv folder to /civic/packages/, then perform bootstrap, build and start and verify that the package's web site runs
• add @hackoregon/component-library as dependency to the new CRA app, re-run init steps and verify the package's web site still runs
• add @hackoregon/webpacker and @hackoregon/civic-babel-presets to the CRA app, re-run init steps and verify the package's web site still runs

[MikeTheCanuck]

Solution Prereqs

• project's package.json includes working scripts for build, start and test - "working" means no errors and no unexplainable warnings
• start script results in a site that returns useable output to HTTP GET / (no routing required to get to site's home page)
• output from build script renders a fully standalone, client-side-only web site that can be hosted by any HTTP server (i.e. that will work with AWS S3 HTTP hosting)
• no conflict between the package's dependencies and the existing dependencies in the master package.json
• no secrets stored in plaintext in any git-committed files
• no API calls require authentication