CRA(Create React App)에 tslint, eslint, prettier 적용하기

지금 만드는 토이프로젝트에 tslint, eslint, prettier을 적용한 겸 세팅값을 블로그에도 적어둔다.

CRA로 만든 프로젝트에 따로 webpack config를 eject 하지 않고 위에 3개를 적용할 수 있는 방법임.

Step 1: 온갖 devDependencies를 설치한다.

npm i -D @types/react typescript-eslint/eslint-plugin typescript-eslint/parser eslint eslint-config-prettier eslint-config-react eslint-loader eslint-plugin-prettier prettier tslint typescript

다만 여러분이 이 글을 보는 시점에 https://github.com/prettier/prettier-atom/issues/505#issuecomment-516791742 이 Issue가 해결되지 않았다면 eslint는 5.16.0 버전으로 설치한다(19년 9월 기준으로 v6임)

// eslint를 5.16.0 으로 박아둔 버전
npm i -D @types/react typescript-eslint/eslint-plugin typescript-eslint/parser eslint@5.16.0 eslint-config-prettier eslint-config-react eslint-loader eslint-plugin-prettier prettier tslint typescript

왜냐면 에디터 prettier에서 dependency 에러가 나더라. Failed to load plugin 'prettier' declared in 'CLIOptions': Cannot find module 'eslint-plugin-prettier' 라고 나옴. eslint를 5.16버전으로 다운그레이딩하면 이 에러가 사라진다. 곧 Fix PR 만든다고 했으니 미래에는 에러 해결이 되었길…

내 package.json은 다음과 같다

"devDependencies": {
    "@types/react": "^16.9.2",
    "@typescript-eslint/eslint-plugin": "^2.3.0",
    "@typescript-eslint/parser": "^2.3.0",
    "eslint": "^5.16.0",
    "eslint-config-prettier": "^6.3.0",
    "eslint-config-react": "^1.1.7",
    "eslint-loader": "^3.0.0",
    "eslint-plugin-prettier": "^3.1.1",
    "prettier": "^1.18.2",
    "tslint": "^5.20.0",
    "typescript": "^3.6.3"
  },

Step 2: eslint 셋업을 하는 .eslintrc.json 파일을 만든다

eslint의 세부사항을 셋업할 수 있는 파일을 루트폴더에 생성한다. 잘 보면 타입스크립트와 프리티어 세팅 모두 박혀있다.
.eslintrc.json

{
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier/@typescript-eslint",
    "plugin:prettier/recommended"
  ],
  "plugins": ["react", "@typescript-eslint", "prettier"],
  "env": {
    "browser": true,
    "jasmine": true,
    "jest": true
  },
  "settings": {
    "react": {
      "pragma": "React",
      "version": "detect"
    }
  },
  "parser": "@typescript-eslint/parser"
}

Step 3: 몇몇 파일에 eslint를 disable시킬 .eslintignore 파일을 만든다

서비스워커 파일이나 tests 폴더나 legacy 소스들에는 eslint를 끄고싶은 분들도 있을거다. ignore할 수 있는 파일을 만든다.

.eslintignore

src/registerServiceWorker.js
src/**/__tests__/**

Step 4: 타입스크립트 린트 세팅 파일인 tslint.json을 만든다

TSlint 셋업을 해준다. 요거 키면 .tsx 파일들에 빨간줄이 무지막지하게 나온다.

tslint.json

{
    "defaultSeverity": "error",
    "extends": [
        "tslint:recommended"
    ],
    "jsRules": {},
    "rules": {
      "quotemark": false
    },
    "rulesDirectory": []
}

Step 5: 예쁘게 코드 포매팅을 해주는 프리티어 세팅 파일인 .prettierrc 를 만든다

이렇게 프리티어 세팅을 해주고 VSCode에서 mac기준 shift + option + f를 누르면 세팅값대로 코드를 예쁘게 성형해준다. 입맛대로 세팅을 해준다. 프리티어 다큐멘테이션 참고하삼 https://prettier.io/docs/en/options.html 아래는 제 세팅

.prettierrc

{
  "singleQuote": true,
  "semi": true,
  "useTabs": false,
  "tabWidth": 2,
  "trailingComma": "all",
  "printWidth": 80,
  "arrowParens": "always",
  "orderedImports": true
}

(optional) Step 6: 이제 다했당. package.json에 eslint 바로 고쳐주는 스크립트를 짜둔다

lint:fix 란 이름으로 eslint fix 스크립트를 짜두면 언제든 npm run lint:fix 명령어로 린트 픽스를 할 수 있다. (하지만 난 파일마다 수동으로 단축키를 통해 고치는걸 선호하지)

"scripts": {
    ...
    "lint:fix": "eslint './src/**/*.{ts,tsx}'"
  }

끗!
이제 열시미 js랑 tsx 파일 린트에러를 고치면 됩니다.

적용한 파일은 https://github.com/milooy/TellMe/commit/d2c5520b9d4c0ebfac2629ca2f02066afbeb61b8 참고

[React] External component를 StyledComponent로 감쌌을 때 ‘Warning: Unknown props’ 워닝 해결

Problem

에러가 났을 때 빨간 글자색을 보여주기 위해 StyledComponent에 hasError 프로퍼티를 넘기고

<StyledField hasError={hasError} />

이를 스타일링만 하기 위해 StyledComponent에서만 받아 썼더니

const StyledField = styled(Field)`
  color: ${({ hasError }) => (hasError ? "red" : "black")};
`;

Warning: React does not recognize the errorMessage prop on a DOM element. 에러가 났당. 컴포넌트를 감싼에서만 prop을 쓰고 그 안쪽의 “에서는 errorMessage prop을 안써서 나는 워닝이다.
Screen Shot 2019-09-19 at 4.56.18 PM

Solution

spread operator(...rest)로 hasError를 제외한 나머지 properties만 Field 컴포넌트에 내려보내주면 된다. 코드 드럽네

const StyledField2 = styled(({ hasError, children, ...rest }) => (
  {children}
))`
  color: ${({ hasError }) => (hasError ? "red" : "black")};
`;

Refer

https://github.com/styled-components/styled-components/issues/305

Github Pages로 배포할 폴더 변경하기

결론: subtree를 만들어서 gh-pages브랜치에 원하는 폴더만 올리면 된다.

  1. .gitignore에서 배포 원하는 폴더를 주석처리 (e.g. /public, /dist)
  2. 원하는 폴더를 add하고 commit한다: git add 폴더이름 &amp;&amp; git commit -m "Initial subtree commit"
  3. 서브트리로 gh-pages에 푸시 해준다: git subtree push --prefix 폴더이름 origin gh-pages

두번째 푸시부터 안되는 분들은 아래 3번째 명령어를 써보셔요

  1. git add docs && git commit -m “Subtree commit”
  2. git subtree push –prefix docs origin
  3. git push origin git subtree split --prefix docs master:gh-pages –force

refer: https://gist.github.com/cobyism/4730490

VS Code에 console.log shortcut 추가하기

Background

처음에는 emmet 방식처럼 간략한 텍스트를 입력하고 tab을 누르면 자동완성 되는 방향으로 했는데 반응이 너무 느려서 그냥 명령어 + 탭으로 보이는 경우가 왕왕 있었다. 그래서 스니펫 말고 키보드 쇼트컷 방식을 찾아봤다.

How to

  1. Code > Preferences > Keyboard Shortcuts를 들어간다

2. 상단의 ‘keybindings.json’ 클릭

3. 오른쪽의 Custom 영역에 원하는 키로 덮어쓴다. 나는 console.log("변수이름", 변수")` 식으로 자주 사용해서 snippet에 그렇게 입력해주고 ctrl+shift+l로 단축키를 엮어줬다.

// Place your key bindings in this file to overwrite the defaults
[
    {
        "key": "ctrl+shift+l",
        "command": "editor.action.insertSnippet",
        "when": "editorTextFocus",
        "args": {
            "snippet": "console.log('$1', $2);$0"
        }
    }
]

4. 에디터에서 단축키를 눌러보면 잘 작동하는걸 볼 수 있다. 위에서 $1, $2로 원하는 위치에 숫자를 적어주면 그 곳으로 자동으로 포커스가 이동한다. $1에 원하는 텍스트를 입력하고 tab을 치면 $2로 넘어간다. 끝나면 $0으로 간다.

5. 즐코딩!

+ 단축키 없이 snippet 만들기

Preferences > User Snippets > javascript.json에 아래와 같은 코드를 넣는다

"Print to console": {
		"prefix": "log",
		"body": [
			"console.log('$1');",
			"$2"
		],
		"description": "Log output to console"
	}

lodash fp로 함수형 프로그래밍 하기

왜 함수형으로 코드를 쓰는가

  • Explicit한 코드를 Implicit(암묵적)하게 바꾼다는 이점
  • Explicit하게 짠 제곱함수
function squareAll(numbers) {
    var squared = [];
    for (var i=0; i < numbers.length; i++) {
        squared.push(numbers[i] * numbers[i]);
    }
    return squared;
}

squareAll([1, 2, 3, 4]); // [1, 4, 9, 16]
  • Implicit하게 짠 제곱함수.
function squareAll(numbers) {
    return numbers.map(num => num * num);
}
squareAll([1, 2, 3, 4]);
- 루프를 도는것과 새로운 배열을 만드는걸 `map`메서드에 위임시켰다.
- 읽기 쉬워지고 에러를 낼 가능성이 적어짐.
- 하지만 numbers배열에서 이를 불러내야 함.

– lodash fp로 조금 더 Implicit하게 짠 제곱함수

const map = require('lodash/fp/map');

const squareAll = map(num => num * num); // array.map으로 접근하지 않고 바로 map을 부름. 그리고 함수에 arguments도 없음(커리되어서)

squareAll([1, 2, 3, 4]);
  • lodash/fp의 함수들은 기본적으로 커리되어있다.
  • 그래서 기존에 익숙했던 map(array, function)이 아닌 map(function, array) 순이라고 생각하면 된다.
  • 더이상 numbers argument를 받지 않아도 되며, 이는 point-free프로그래밍의 컨셉이다.
  • 또다른 이점들은 적은 라인의 코드로 읽기도 좋으며, 테스트랑 유지보수 하기도 좋다는 것이다.

커링(Currying)

  • 어떤 함수가 특정한 개수의 인자를 기대하는데, 이보다 적게 인자를 넣었을 때 남은 인자들을 새로운 함수로 받을 수 있는것을 커링(Currying)이라 한다.
  • 모든 인자들이 전달되었을 때 원하는 결과가 반환된다.
const curry = require("lodash/fp/curry");

const sayMessageTo = curry((msg, name) => `${message}, ${name}!`);

sayMessageTo("Hello", "Yurim"); // 원하는 결과 바로 반환. "Hello, Yurim!"
const sayBye = sayMessageTo("Bye"); // message를 받았으니, name을 받을 수 있는 새로운 함수 반환
sayBye("Josh"); // 모든 인자 받았다. "Bye, Josh!"
  • 아까 했던 map도 map(num =&gt; num * num, [1,2,3,4])처럼 한번에 호출할 수 있음

함수 조립하기 (Compose functions)

  • 함수를 조립한다는 컨셉은 작은 함수들로 큰 함수를 만든다는 것이다. 각 함수는 리턴된 값을 다음 함수에 넘긴다.
const flow = require('lodash/fp/flow');
const escape = require('lodash/fp/escape');
const trim = require('lodash/fp/trim');

const sanitise = flow(escape, trim);

sanitise('    <html>    '); // <html>
  • 암묵적이고 선언적으로 함수 짜기. 어떻게 되어야하는지 코드를 짜는게 아니고 어떤 일이 일어나야하는지 선언하기.
  • lodash/fp의 함수들은 기본적으로 커리가 되어있어서 더 적은 인자를 넘기면 함수를 돌려준다.
  • composition이 가능한 함수들은 하나의 argument를 넘기고 하나의 value를 다음 함수로 넘기는 형태여야 한다. 맨 처음 함수는 하나 이상의 argument를 넘길 수 있지만 single value를 리턴해야 하는건 동일하다.

Point-free

  • 포인트 프리 스타일(Tacit이라고도 부름) 프로그래밍은 함수가 그들이 수행해야 하는 arguments를 명시하지 않는 패러다임이다.
// Before
function isSuccess(response) {
  if (response.status === 200) {return true;}
}
isSuccess(response);

// After
const isSuccess = flow(get('status'), isEqual(200));
isSuccess(response);

순수 함수(Pure functions)

  • 외부 스코프에 의존이 없는 함수. 넘긴 인자에만 영향받고 이를 변형하면 안되며 새로운 객체를 넘겨야 한다.

Refer

https://simonsmith.io/dipping-a-toe-into-functional-js-with-lodash-fp/

[Git] Pull Request를 보내기 전에, Rebase를 해야 할까요 혹은 merge commit을 만들어야 할까요?

Rebase vs Merge commit

목적: PR을 보내기 전에 내가 보낼 브랜치가 master와 fast-forward(컨플릭트 없이 바로 머지될 수 있는 상태)상태가 되도록 만든다.

그런데 매번 이렇게 할 필요는 없고,
1. PR을 보낼 브랜치가 master보다 너무 옛날 상태일때나
2. GitHub에서 PR을 보냈더니 ‘merge conflict warning’이 페이지에서 보일 때 (같은 코드가 고쳐졌을때 자동으로 보임)
만 하면 된다.

방법 1. (내 브랜치에 먼저 머지 후 풀리퀘)

  • master의 최신 상태를 내 브랜치에 merge시킨다.
  • master와 내가 똑같은 파일을 고쳤다면 conflict가 날 것이다. 그럼 해결한다.
  • 해결해서 만들어진 merge commit을 push한다 (merge commit이 새로 하나 생김)
  • 장점: 한 번의 ‘merge’만으로 쉽게 해결할 수 있다.
  • 단점: merge commit이 생겨서 깔끔하지 않다. 코드 수정한 의미있는 커밋만 보고싶을텐데 말이다.

방법 2. (리베이스 후 풀리퀘)

  • master의 최신 상태를 base로 해서 내 브랜치를 rebase한다.
  • rebase의 원리는, 내가 원하는 커밋을 base로 해서 내 브랜치가 마치 그 커밋에서 딴 것처럼 기록을 조작하는 것이다.
  • 내부에서 돌아가는 방식은, 내가 원래 딴 커밋에서부터 내가 목표하는 base커밋까지 하나씩 옮겨가면서 새로 커밋을 하는것이다.
(원래상태)

[3시커밋 --- 4시커밋 --- 5시커밋] 
  ㄴ--- 내브랜치커밋

(5시커밋을 베이스로 리베이스를 실행한다)
[3시커밋 --- 4시커밋 --- 5시커밋] 
              ㄴ--- 내브랜치커밋 // 한 커밋씩 옮겨가며 commit한다. 컨플릭이 나면 고쳐준다.

(Continue rebase를 누른다)
[3시커밋 --- 4시커밋 --- 5시커밋] 
                        ㄴ--- 내브랜치커밋 // 목표하는 5시커밋까지 왔다. 컨플릭이 나면 고쳐준다

  • 모두 완료되었으니 push를 해야하는데, 히스토리를 조작하는 위험한 작업이므로 force옵션을 넣어 push해야한다.
  • 결과: 내브랜치커밋이 master의 최신 상태인 5시커밋에서 딴 것처럼 히스토리가 조작된다. 그래서 내 브랜치에서 master로 Pull Request를 보냈을 때 fast-forward(컨플릭트 없이 바로 머지할 수 있는) 상태가 된다.
  • 장점: merge commit없이 깔끔한 커밋 히스토리를 만들 수 있다.
  • 단점: 만약 중간에 코드 컨플릭트가 나면 그 사이에 있는 커밋들 모두에서 컨플릭트를 수정해줘야 할 수 있다. 귀찮다.

언제 무엇을 써야하나?

  • Type 0. master에서 딴지 그리 오래 되지 않은 브랜치: 그냥 PR을 보내본다. conflict warning이 보이면 그 때 2번이나 3번 방법을 쓴다
  • Type 1. 내 브랜치에 커밋이 엄청 많다. 그리고 master랑 비슷한 코드를 만져서 컨플릭트가 날 가능성이 높다: 방법 1(내 브랜치에 먼저 머지 후 풀리퀘)을 사용한다.
  • Type 2. 내 브랜치에 커밋이 그리 많진 않다. 깔끔한 커밋 히스토리를 남기고 싶다(오픈소스 등): 방법 2(rebase)를 사용한다.