- "start": "TSC_COMPILE_ON_ERROR=true & PORT=3080 & react-scripts start",
- React has a bug where it refuses to start due to internal ESLint rules failing
- TSC_COMPILE_ON_ERROR forces the server to always start
- "test_coverage": "yarn test -- --coverage --watchAll=false --collectCoverageFrom=/src/utils/",
- Only does test coverage for utils folder as UI components will be handled by storybook
- "compile": "tsc --noEmit && yarn lint"
- Run to ensure that the code has no major problems
Default settings were used
- Import files using absolute imports such as
src/utils/Sample
instead of../../src/utils/Sample
- This makes it easier to move files around
- @typescript-eslint/eslint-plugin
- @typescript-eslint/parser
- eslint
- eslint-config-prettier
- eslint-plugin-prettier
- eslint-plugin-react
- prettier
- ESLint with Typescript
- ESLint with Prettier
- ESLint with React rules
- 'prettier/prettier': 'warn'`
- Prettier is about formatting, and formatting should never throw errors
- 'react/display-name': 'warn',
- Not a breaking issue and should not be an error.
- '@typescript-eslint/no-unused-vars': ['warn', { argsIgnorePattern: '^_' }],
- Not a breaking issue and should not be an error.
- 'no-console': ['warn', { allow: ['info', 'warn', 'error'] }],
- Only console.log should be warned as developers use it to print info but forget to remove it
- Info, warn & error are usually used explicitly for a good reason
- 'react/prop-types': 'off' // Props are handled by Typescript
- Proptypes are handled by Typescript
- printWidth: 100
- 80 is too short. 100 is perfectly readable for anyone with a widescreen monitor.
Configs - environmental or otherwise - should be loaded from a Cfg
file, so that there is a centralized place that keeps track of all configurations to avoid duplicate configurations or fragmentation.
Environment variables should never be accessed directly from process.env due to the following reasons:
- It isn't typesafe and as such doesn't offer autocomplete
- It does not warn you if you made a mistake
- It makes it harder to refactor
Instead, define it inside Env
and access it from Cfg
.
Due to the complications of handling multi environments (dotenv, babel, webpack), the limitations of some frameworks (Android/iOS), and too many frameworks trying to be smart, I've found that the most straightforward way to handle multiple environments is simply by replacing the environment files before compilation. It may be crude, but it's simple and it works.
.cfg.xxx
- xxx denotes the environment
file1 => file2
- Copies file1 into the location of file2
yarn start
- Will default to
local
environment
ENV=develop yarn start
- Will patch all files located in env/develop/.cfg.develop
yarn storybook