Stack Selection

Build, Language, Linting

Webpack

Webpack instead of gulp, bower, <some unproven competitor w/o a major community like Rollup or Parcel>.

Typescript

TypeScript for JS Type-casting and Polyfilling instead of Flow, Babel, .

1. caveat: use babel for what TS can’t do yet, aka include browser-x’s polyfills.
2. TS is an MS project
   1. ties in great w/ VS Code
   2. Benefits of Enterprise sponsorship
3. TS is not “a superset of JS”, its better understood as “just the good parts” (Crockford probably loves it!) of JS.
   1. TS and TSLint warns/errors against implementing the same idea multiple ways.
   2. Consistency helps navigating a large codebase.
4. TS is a lot faster than Flow
   1. Tight integration w/ VSCode
   2. Microsoft’s experience proves itself compared to Facebook
   3. No separate “Flow Service” (I assume FB uses this to offload Type-checking during development to a cloud service)
5. TS can output a declarations file which lends to modularization
6. Even when you don’t write tests, TS w/ VSCode will help a developer catch a lot of bugs before even hitting save.
   1. “ it helps the committed source have cleaner features, less buggy commits.”
7. The only thing Flow can do better than TS is generate prop-types for client-side runtime debugging
   1. but... why do runtime debugging? (aka React PropTypes)
      1. Loading a browser takes resources away from the IDE & hot-rebuilder, chrome is especially power consumptive if dev-ing on the road.
      2. Typecasting JS and using GraphQL Schemas
   2. the build would error which means my dev-feedback cycle eliminates the time invested in browser debugging.
   3. Updating existing react code from propTypes to TS is easy w/ https://github.com/lyft/react-javascript-to-typescript-transform
8. Flow is dying! Facebook's type casting system is being shed by its own opensource projects. In early 2019 Facebook's own Jest project declared its intention to move to Typescript, and Expo said they were doing the same.

TSLint

TSLint replaces ESLint (because TS) and Prettier, until 2019Q3. As of January 2019 Microsoft has announced alignment w/ ESLint in favor of TSLint.

1. Arguments for just TSLint, instead of in combination with ESLint
   1. You can use Prettier… but when I used the TS-wrapper it was buggy
   2. You can use ESLint…
      1. but why care what the output code looks like, especially when it gets minified in Prod?
      2. but why have a second set of rules

Developer (Node & Git) Tooling

Projects that are started from TGRStack resources come with a lot of tooling baked in.

nps - NPM Package Scripts

Even though npm scripts have a ton of advantages (learn more), it can grow into an unmaintainable mess in your package.json file. Part of the problem is we're configuring scripts in json which has fundamental issues (like no comments).

The first thing to checkout in a repo is typically the "scripts" section of a package.json file. A few minimal scripts are available there, but the majority of scripts are available in a scripts/ folder powered by https://github.com/kentcdodds/nps .

Instead of running commands with npm run use nps .

cz-emoji - Commitizen w/ Gitmoji

This is a combination of a few modules to create a nice, uniform commit messaging experience.

• GitMoji (https://gitmoji.carloscuesta.me/) is a specification for emojis that relate to developer work
• Commitizen is a specification for formatting commit messages so 3rd party tools (jira) can easily integrate w/ the commit log
• Commitizen is also a tool that provides a prompt for developers to follow when writing commit messages
• A technology that will replace Commitizen in 2019 is called Commitlint

Combining these ideas, cz-emoji is a commit message prompt that incorporates the gitmoji specification to allow developers to easily make uniform commit messages with emojis!

Data Caching and Communication

Apollo Server (GraphQL)

The typical story of a company API spec begins with a MVP API backend for a specific DB and then use a schema like swagger to scalably build an endpoint w/ an explorer. Then the frontend people use the explorer and their teams standards to write client side queries. Then infra. people get involved and want to monitor what queries are popular or inefficient. Cut to the chase with Apollo server and Apollo engine, and share gql code with the frontend!

1. a universal communication layer between services and easily use the right DB for the project
2. Swagger (REST API Explorer/Schema) for free via GraphQL Playground
3. API analyzer with Apollo Engine

Apollo Client (GraphQL)

Developers using this library only have to learn one methodology for retrieving, caching, and manipulating client side data. Way too much effort has been invested by the React community into Redux and other ViewModel methodologies which becomes a monumental topic for new developers learning Redux and the ecosystem that grew around it. Skip the hike and just learn apollo client.

1. Apollo Client 2.5 replaces Redux (Really!!) without the Apollo-link-state library (the plugin becomes integrated into the core code base)
2. Many devs have spent a lot of effort learning Redux, but with Apollo State your modules can access a cache using graphql methods
   1. Cache optimization is done by the library!
   2. For queries add “@client”
   3. For mutations add “cache.writeData({data})”

User Interface

REACT

React instead of any other view library (Vue, Ember, etc.)

1. It’s very easy to find React developers
2. Angular’s
   1. 2-directional binding can be confusing compared to pure functional programming (industry good practices)
   2. Imperative > Declarative
3. Components
4. Any templating language is stupid. You have a programming language, why create a second one

Don't use SSR with React if:

1. visualization
2. client-side decryption (sending encrypted data, and client's use their KMS to decrypt the data after transmission)