Configure for TypeScript use

Author: Andre Rabold

.babelrc

@@ -8,6 +8,7 @@
         }
       }
     ],
+    "@babel/preset-typescript",
     "@babel/preset-react"
   ],
   "plugins": [],

README.md

@@ -10,16 +10,16 @@ Lightweight boilerplate project to setup a React 16 web application on AWS Lambd
 - Universal app; server-side rendering with dynamic configuration context passed from backend to browser.
 - Self-contained; no additional setup steps necessary other than running `npx sls deploy`.
 - Lightweight; no mandatory `redux`, `react-router`, `sass`, `less` or any other 3rd party dependency for full flexibility.
-- Full ES6/7/8/9/10 with latest JavaScript features supported using Babel 7 and Webpack 4.
+- Full [TypeScript](https://www.typescriptlang.org/) support using Babel 7 and Webpack 4.
 - Working [Jest](https://jestjs.io/) test environment.
 
-[Looking for the TypeScript version of this boilerplate?](https://github.com/arabold/serverless-react-boilerplate/tree/typescript)
+[Looking for the plain JavaScript version of this boilerplate?](https://github.com/arabold/serverless-react-boilerplate/)
 
 ## Overview
 
 ### How Does It Work?
 
-The idea is that we use AWS Lambda to serve the dynamic part of our app, the server-side logic, and perform the server-side rendering. For all static data like images, stylesheets and even the app's `index.jsx` that is loaded in the browser, we use an S3 bucket for public hosting.
+The idea is that we use AWS Lambda to serve the dynamic part of our app, the server-side logic, and perform the server-side rendering. For all static data like images, stylesheets and even the app's `index.tsx` that is loaded in the browser, we use an S3 bucket for public hosting.
 
 This combination makes our app fast and incredibly scalable. AWS will spin up new Lambda instances once your number of users increases, handling even the largest spikes fully automatically, while incurring virtually no costs when your app isn't used. At the same time S3 provides a robust and fast platform for your static content so you don't have to waste your own computing resources.
 
@@ -61,8 +61,8 @@ The project is based on the [Serverless Framework](https://serverless.com) and m
 
 Though we use the same source code for both the server-side and client-side rendering, the project will be packaged into two distinct bundles:
 
-1. Backend code running on AWS Lambda. The main entry point is `./src/server/index.jsx`. The packaging is controlled by `webpack.server.config.js` and optimized for Node.js 12.
-2. Frontend code hosted in an S3 bucket and loaded by the browser. Main entry point is `./src/browser/index.jsx`. It's packaged using the `webpack.browser.config.js`, optimized for web browsers. The output files will have their content hash added to their names to enable long term caching in the browser.
+1. Backend code running on AWS Lambda. The main entry point is `./src/server/index.tsx`. The packaging is controlled by `webpack.server.config.js` and optimized for Node.js 12.
+2. Frontend code hosted in an S3 bucket and loaded by the browser. Main entry point is `./src/browser/index.tsx`. It's packaged using the `webpack.browser.config.js`, optimized for web browsers. The output files will have their content hash added to their names to enable long term caching in the browser.
 
 ## Customization
 
@@ -72,7 +72,7 @@ Update the `serverless.yaml` with your project name and additional resources you
 
 ### Configuration
 
-The frontend as well as the server-side code running on AWS Lambda share a common application configuration. Currently it is used for injecting the application name from the `public/manifest.json` as well as setting the public host names. You can extend the configuration by adding your own variables to `src/server/config.jsx`. They will become available in both your backend and frontend code via the `useConfig` hook:
+The frontend as well as the server-side code running on AWS Lambda share a common application configuration. Currently it is used for injecting the application name from the `public/manifest.json` as well as setting the public host names. You can extend the configuration by adding your own variables to `src/server/config.tsx`. They will become available in both your backend and frontend code via the `useConfig` hook:
 
 ```js
 import useConfig from "../components/useConfig";

handler.js renamed to handler.ts

@@ -1,7 +1,8 @@
 import "source-map-support/register";
 import render from "./src/server/render";
+import { Context, APIGatewayEvent, APIGatewayProxyResultV2 } from "aws-lambda";
 
-export const serve = async (event, context) => {
+export const serve = async (event: APIGatewayEvent, context: Context): Promise<APIGatewayProxyResultV2> => {
   return {
     statusCode: 200,
     headers: {