요소의 특정한 부분에 CSS 속성을 적용할 수 있도록 선택자에 추가하는 키워드입니다. 요소에 CSS 속성을 적용하는 것과 같은 방법으로 다양한 CSS 속성을 적용할 수 있기 때문에 하나의 하위 요소처럼 사용할 수 있어서 가상 요소라고 합니다.

가상 요소 리스트

• ::before: 요소 내용 앞쪽에 새 컨텐츠를 추가합니다.
• ::after: 요소 내용 끝에 새 컨텐츠를 추가합니다.
• ::selection: 마우스 드래그로 선택한 텍스트 컨텐츠 영역을 선택합니다.
• ::marker: 목록 요소(li) 앞에 붙는 마커를 선택합니다.
• ::first-letter: 현재 웹 브라우저에 보이는 상태를 기준으로 요소의 텍스트 컨텐츠 첫 글자를 선택합니다.
• ::first-line: 현재 웹 브라우저에 보이는 상태를 기준으로 요소의 텍스트 컨텐츠 첫 줄 내용을 선택합니다.

::before, ::after만 새 컨텐츠를 추가하는 가상 요소이고, 나머지는 콘텐츠의 특정 영역을 선택하는 가상 요소입니다.

가상 요소 작성 방법

가상 요소는 앞에 콜론(:)을 2개 붙여서 표기합니다.

가상 클래스는 콜론을 1개 붙여서 표기합니다. CSS1, CSS2 때는 가상 요소도 콜론 1개로만 표시했었는데 CSS3에 오면서 가상 클래스와 가상 요소를 구분하기 위해서 콜론을 2개 붙여서 표기하기 시작했습니다.

:before로 작성해도 가상 요소가 정상적으로 작동하는 이유는 웹 브라우저가 콜론 1개와 2개의 표기를 모두 지원하기 때문입니다. 그래도 가상 요소는 콜론을 2개 붙이는 것이 CSS3의 표준 표기 방법입니다.

span::before {
    content: "";
    width: 120px;
}

위처럼 가상 요소는 선택된 요소에 의존적인 키워드입니다.

그렇다면 가상 클래스는 무엇일까요? 🤔

가상 클래스

사용자가 요소에 마우스 포인터를 올리거나 클릭하는 등 특정 이벤트마다 스타일을 적용할 수 있도록 선택자에 추가하는 키워드입니다.

개인적인 경험으로는 가상 요소보다는 가상 클래스를 더 많이 사용하는 것 같습니다. 특정 부분에 CSS 속성을 정하는 가상 요소와 달리 해당 요소의 특정 이벤트 시점에 스타일을 적용하는 것이 가상 요소와 가상 클래스의 가장 큰 차이점입니다.

대표적인 가상 클래스 리스트

• :link - 방문한 적이 없는 링크
• :visited - 방문한 적이 있는 링크
• :hover - 마우스를 롤오버 했을 때
• :active - 마우스를 클릭 했을 때
• :focus - 포커스 되었을 때 (input 태그 등)
• :first - 첫번째 요소
• :last - 마지막 요소
• :first-child - 첫번째 자식
• :last-child - 마지막 자식
• :nth-child(2n+1) - 홀수 번째 자식

가상 클래스를 사용하면 문서 트리 콘텐츠 뿐만 아니라 탐색기 히스토리(:visited 등), 콘텐츠의 상태, 마우스의 위치와 같은 외부 인자와 관련된 경우에도 스타일을 적용할 수 있습니다.

가상 클래스 작성 방법

가상 클래스는 앞에 콜론(:)을 1개 붙여서 표기합니다.

button:hover {
  color: blue;
}

정리

기본에 충실하자.. 😎

출처

• https://blogpack.tistory.com/1025
• https://blueshare.tistory.com/405
• https://ofcourse.kr/css-course/가장-클래스-선택자

오늘은 Promise에 대해서 이야기를 나눠보려고 합니다.

요즘 들어서 기본 개념이 매우매우 부족하다는 생각을 하고 있습니다.. 🤦‍♂️ 사실 Promise에 대해서 공부하려고 하는 것도.. axios 라이브러리에 대해서 찾아보다가.. 이해가 잘 되지 않아서.. 찾아보게 되었습니다..

이러면서.. react-query와 같은 라이브러리를 사용하겠다는 제 자신이 조금 부끄러워집니다.. 💩 그래도 이렇게 하나씩 배워가는거 아니겠나..! 라는 생각으로 정리해보려고 합니다.

Promise

• 자바스크립트 안에 내장되어 있는 객체(Object)
• 비동기 동작을 위한 객체(Object)
• state와 Producer vs Consumer 2가지의 포인트를 가지고 개념을 이해하는 것이 좋다

Promise 생성

const promise = new Promise((resolve, reject) => {
    ... // executor
})

Promise는 위와 같은 문법으로 생성할 수 있습니다.

new Promise() 에 전달되는 함수는 executor라는 이름을 가지고 있는데, (resolve, reject) => {}와 같은 형태를 가지고 있습니다. executor함수는 new Promise가 생성될 때 자동으로 실행됩니다.

executor의 인수

executor는 resolve, reject 2가지 인수를 받을 수 있습니다. resolve와 reject는 자바스크립트에서 자체적으로 제공하는 콜백 함수입니다. 따로 선언할 필요 없이 executor 함수 안에 작성만 해주면 됩니다.

대신 executor에서는 결과를 얻는 시점과 상관없이 상황에 따라 resolve와 reject 콜백 함수 중 하나를 반드시 호출해야 합니다. 왜냐하면, executor는 생성과 동시에 실행하게 되는데 executor 내부에서 로직을 처리하게 됩니다. 처리가 끝나면 바로 resolve 혹은 reject 콜백 함수를 호출하게 됩니다.

resolve, reject

• executor의 처리 성공 여부에 따라 실행되는 콜백함수
• resolve(value): 작업을 성공한 경우 결과(value)와 함께 호출
• reject(error): 에러 발생 시 에러 객체를 나타내는 error와 함께 호출

Producer

• 정보를 제공하는 주체

• 파일을 읽어나 네트워크 작업을 하는 등의 시간이 오래 걸리는 작업을 수행하고, 수행한 결과에 대한 데이터나 에러를 반환한다

  const promise = new Promise((resolve, reject) => {
    ... // executor
    setTimeout(() => {
        // 성공
        resolve('success!')
  
        // 실패
        reject(new Error('error!'))
    }, 1000)
  })

executor의 로직(파일을 읽거나 네트워크 작업과 같은 작업)을 수행한 후 성공했을 때는 resolve()를 통해서 받아온 값을 전달할 수 있습니다. 반대로 실패한 경우에는 reject()와 Error 객체를 통해서 실패에 대한 값을 전달하게 됩니다. Error 객체는 자바스크립트에서 제공하는 객체 중 하나입니다.

Consumer

• 정보를 사용하는 주체
• new Promise 생성자가 반환하는 promise 객체
• then, catch, finally를 이용해서 값을 받아올 수 있다

Promise의 상태와 값 (Consumer의 상태)

new Promise 생성자가 반환하는 Promise는 상태(status)와 값(result)을 가지게 됩니다. 상태는 pending, fulfilled, rejected가 있고, 상태에 따라 값(result)이 바뀌게 됩니다. 이러한 상태의 변경은 producer에서 어떠한 함수를 호출하는가에 따라 달라지게 됩니다.

pending

• promise₩ 객체의 초기 상태 혹은 실행 중인 상태
• result는 undefined

fulfilled

• producer에서 resolve가 호출되면 나타나는 상태 (성공)
• result는 resolve(value)의 value로 값이 바뀌게 된다.

rejected

• producer에서 reject가 호출되면 나타나는 상태 (실패)
• result는 reject(error)의 error로 값이 바뀌게 된다.

then, catch, finally

const promise = new Promise((resolve, reject) => {
    resolve('success!')
    reject(new Error('error!'))
})

then

• resolve 콜백 함수를 통해서 전달된 값을 사용할 수 있다
• 또한 promise도 전달할 수 있다.

proimise
    .then((value) => console.log(value)) // success!

value라는 파라미터는 resolve에서 전달하는 값을 받는 파라미터입니다. 그래서 value라는 명칭을 고정해서 사용해야 하는 것은 아니고 적절한 명칭을 사용하면 됩니다.

catch

• reject 콜백 함수를 통해서 전달된 에러에 대한 값을 사용할 수 있다

promise
    .catch((error) => console.log(error)) // Error: error! at ...

reject 콜백함수에서 전달한 error에 대한 값을 catch로 받지 않게 되면 Uncaught 에러로 표현되게 됩니다. 그래서 에러 핸들링을 위해서 catch를 이용해서 실패에 대한 케이스를 처리해줘야 합니다.

finally

• executor의 성공과 실패 여부와 상관없이 무조건 호출되는 함수

promise
    .finally(() => console.log('finally!'))

만약 promise에 대한 then, catch 작업을 진행하고 싶다면 아래와 같이 Promise Chaining 형식으로 작성해야 합니다. .then에 대한 반환 값도 promise이기 때문에, .catch에 대한 처리를 진행할 수 있습니다.

promise
    .then((value) => console.log(value))
    .catch((error) => console.log(error))

const promise = new Promise((resolve, reject) => {
    console.log("doing something...");

    setTimeout(() => {
        reject(new Error("no network"));
    }, 1000);
});

promise
    .then((value) => console.log(value))
    .catch((error) => console.log(error))
    .finally(() => console.log("finally"));

위와 같은 코드에서는 Error: no network at ...와 같은 메시지와 finally 문자열이 콘솔에 찍히게 될 것입니다. 만약 catch에 대한 처리를 해주지 않아도 Uncaught 에러와 함께 finally는 작동하게 됩니다.

Promise Chaining and Error Handling

const getHen = () =>

new Promise((resolve, reject) => {
    setTimeout(() => resolve("hen"), 1000);
});

const getEgg = (hen) =>
    new Promise((resolve, reject) => {
    // setTimeout(() => resolve(`${hen} => egg`), 1000);
    setTimeout(() => reject(new Error(`error! ${hen} => egg`)));
});

const cook = (egg) =>
    new Promise((resolve, reject) => {
    setTimeout(() => resolve(`${egg} => fried`), 1000);
});



getHen()
    // .then((hen) => getEgg(hen))
    // callback 함수를 전달할 때 받아오는 value를 다른 함수에서 바로 호출하는 경우에는 생략이 가능하다.
    .then(getEgg)
    // egg를 받아올 때 문제가 생긴다면 catch를 통해서 다른 것을 전달해줄 수 있다.
    .catch(() => {
        return "bread";
    })
.then((egg) => cook(egg))
.then((meal) => console.log(meal))
.catch(console.log);

마무리

오늘은 Promise에 대해서 알아보았습니다. 자바스크립트 책을 한 권 스터디하는 것도 좋을 것 같다는 생각이 듭니다.. 🤔

Producer와 Consumer의 개념을 사용한 것은 제가 참고한 유튜브에서 사용한 방식이기 때문에 공식적인 단어는 아닌 것으로 알고 있습니다. 해당 내용 참고하셔서 봐주시면 감사하겠습니다. 🙏

출처

• https://www.youtube.com/watch?v=JB_yU6Oe2eE
• https://ko.javascript.info/promise-basics

오늘은 React Hook Form 라이브러리를 이용해서 MUI와 같은 UI 라이브러리 컴포넌트를 제어하는 방법을 같이 나눠보려고 합니다.

우선 React Hook Form 라이브러리에 대한 개념 없이 MUI 컴포넌트를 제어하는 방법을 찾기까지 너무 힘들었습니다.. 💩

대부분의 포스팅에서는 register를 이용해서 input과 같은 컴포넌트를 제어하는 방법을 알려주고 있었는데요. MUI에 적용하기에는 맞지 않는 방법이었고, 제 문제에 대한 해답을 찾기 위해서 굉장히 많은 시간을 사용했습니다. 😢

제가 출처에 남긴 포스팅의 방식을 찾는데 오래 걸린 것은 아니지만.. 문제에 대한 해결 방법이라는 것을 아는데 오래 걸렸던 것 같습니다.. ㅎㅎ

1. Controller 사용하기

React Hook Form 라이브러리에서 제공하는 컴포넌트로, 외부 컴포넌트를 React Hook Form과 연결하여 제어하는데 사용됩니다.

Controller 기능

• 외부 컴포넌트 연결: 외부 컴포넌트를 연결해서 필드를 제어할 수 있습니다. 값을 추적하거나 입력을 관리할 수 있습니다.
• 컴포넌트 속성 설정: name, onChange와 같은 속성을 외부 컴포넌트에 전달하여 필드의 상태를 업데이트 할 수 있습니다.
• 유효성 검증 규칙 설정: rules 속성을 사용하여 필드에 대한 유효성 검사 규칙을 정의할 수 있습니다. 유효성 검사는 자동으로 진행됩니다.

import { useForm, Controller } from 'react-hook-form';
import { TextField } from '@mui/material';

const MyForm = () => {
    const { control, handleSubmit } = useForm();
    const onSubmit = (data) => console.log(data);

    return (
        <form onSubmit={handleSubmit(onSubmit)}>
            <Controller
                name='name'
                control={control}
                rules={{ required: true }}
                render={({ filed }) => (
                    <TextField
                        label='name'
                        {...field}
                    />
                )}
        </form>
    )
}

render 속성에서 렌더링할 컴포넌트를 정의하고 field 속성을 전달해서 해당 컴포넌트 제어를 React Hook Form에게 위임할 수 있습니다.

2. useController 사용하기

이전에 사용한 Controller 컴포넌트와 동일한 권한을 가지는 커스텀 훅입니다. 추가적으로 Controller와 동일한 props와 method를 사용할 수 있습니다.

useController는 재사용 가능한 컴포넌트를 만드는데 유용합니다.

공식문서

import { useForm, useController, UseControllerProps } from "react-hook-form";

type FormValues = { FirstName: string; };

function Input(props: UseControllerProps<FormValues>) {
    const { field, fieldState } = useController(props);
    return (
        <div>
            <input {...field} placeholder={props.name} />
        </div>
    );
};

export default function App() {
    const { handleSubmit, control } = useForm<FormValues>({
        defaultValues: {
            FirstName: ""
        },
        mode: "onChange"
    })
    const onSubmit = (data: FormValues) => console.log(data)

return (
    <form onSubmit={handleSubmit(onSubmit)}>
        <Input control={control} name='FirstName' rules={{ required: true }} />
    </form>
    )
}

위의 코드와 비교했을 때, Controller 컴포넌트를 사용하지 않고, 별도로 정의한 Input 컴포넌트를 제어할 수 있습니다.

하지만 예제에서는 특정 타입에서만 사용할 수 있도록 되어 있기 때문에 이 부분을 제너릭을 활용해서 공통 컴포넌트로 사용할 수 있도록 바꿔줘야 합니다. 추가적으로 별도로 정의한 Input 컴포넌트에 MUI 컴포넌트인 textField를 사용할 수 있지만, textfieldProps를 제대로 넘겨주지 못할 것입니다.

useController + Mui Text Field

interface MuiProps {
    textFieldProps?: TextFieldProps;
}

const Input = <
    TFieldValues extends FieldValues = FieldValues,
    TName extends FieldPath<TFieldValues> = FieldPath<TFieldValues>
>({
    textFieldProps,
    ...props
}): MuiProps & UseController<TfieldValues, TName>) => {
    const { field, fieldState: { error } } = useController(props)

    return (
        <TextField
            {...textFieldProps}
            {...field}
            error={!!error}
            helperText={!!error && error.message}
        />
    )
}

사용

const App = () => {
    const { control, handleSubmit } useForm()

    const onSubmit = (data) => console.log(data)

    return (
        <form onSubmit={handleSubmit(onSubmit)}>
            <Input
                name="FirstName"
                control={control}
                rules={{ required: true }}
                textFIeldProps={{
                    label: "First Name"
                }}
        </form>
    )
}

개인적으로 Controller 컴포넌트를 사용하는 것보다 깔끔하고 편하다고 생각합니다.

추가적으로, 마지막의 useController와 MUI의 textField 컴포넌트를 같이 사용하는 방식은 제가 참고한 포스팅에 훨씬 자세한 설명이 있으니 원문을 참고하시는 것도 좋을 것 같습니다! 🙏🙇‍♂️

만약 저처럼 React Hook Form 라이브러리와 MUI를 같이 사용하고 싶다면, 결국 TextFieldProps를 별도로 처리해줘야 합니다!

1. Controller 컴포넌트 활용하기
2. useController 훅 활용하기 가독성이나 선호도 차이에 따라 위의 2가지 방법 중 선택해서 사용하면 될 것 같습니다! 저의 경우에는 useController 훅을 활용해서 별도로 정의한 Input 컴포넌트를 만들었습니다!

마무리

개인적으로 이번 학습에 처음으로 챗 GPT를 많이 사용한 것 같습니다.. 이전까지는 아직 챗 GPT를 믿을 수 없다는 생각이 많이 있어서 전혀 사용하지 않았는데요. 시간도 부족하고 막막한 느낌이 있어서 사용했더니.. 저에게 좋은 경험을 준 것 같습니다. 👍

그리고 React Hook Form의 공식문서는 너무나도 잘 되어있다는 생각이 들었습니다. 처음부터 공식문서를 살펴 볼 시간이 있었다면.. 오히려 더 빠르게 해결 할 수 있지 않았을까? 라는 생각이 들었네요!

• 해결의 결정타를 날려준 포스팅 주인님 🙏
• 정보의 중심이 되는 공식문서 📚
• 나의 시간을 많이 아껴준 챗GPT ⚙️

삼박자가 잘 맞는 아주 값진 경험이었습니다..⭐️

출처

• https://velog.io/@syoo970/react-hook-form%EA%B3%BC-MUI%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%9C-%EC%9E%AC%EC%82%AC%EC%9A%A9%EC%84%B1-%EC%9E%88%EB%8A%94-Input-%EA%B3%B5%ED%86%B5-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8-%EB%A7%8C%EB%93%A4%EA%B8%B0TypeScript
• https://react-hook-form.com/docs/usecontroller

미디어 유형

장치의 일반적인 범주를 나타냅니다. not이나 only 논리 연산자를 사용할 때를 제외하면 선택사항이며 default value는 all입니다.

• all: 모든 장치에 적합
• print: 인쇄 결과물 및 출력 미리보기 화면에 표시중인 문서
• screen: 주로 화면이 대상
• speech: 음성 합성 장치 대상

논리 연산자

not, and, only와 같은 논리 연산자를 사용해 쿼리를 조합할 수 있습니다.

• and: 다수의 미디어 특성을 조합해서 하나의 미디어 쿼리를 만듬. 쿼리가 참이려면 모든 구성 특성이 참을 반환해야 한다.
• not: 쿼리가 거짓일 때만 참을 반환한다. 쉼표로 구분한 쿼리 목록 중 하나에서 사용한 경우 전체 쿼리가 아닌 해당하는 하나의 쿼리에만 적용된다.
• only: 전체 쿼리가 일치할 때만 스타일을 적용할 수 있도록 사용, 오래 된 브라우저가 스타일을 잘못 적용하지 못하도록 방지할 때 유용하다.
• 쉼표(,): 다수의 미디어 쿼리를 하나의 규칙으로 조합할 때 사용, 하나의 쿼리만 참을 반환해도 규칙 전체가 참이 된다. 논리 연산자 or 처럼 동작한다.

Level 3 모듈에서는 not 키워드를 사용해 단일 미디어 기능을 부정할 수 없고 전체 쿼리만 부정이 가능합니다.

예전의 구형 브라우저에서는 screen and (max-width: 500px) 이라는 쿼리를 단순하게 screen으로만 읽고 스타일을 적용해버렸습니다. 이러한 경우 only screen and (max-width: 500px) 식으로 표현해서 전체 쿼리가 일치 할 때만 스타일을 적용할 수 있도록 설정합니다. only 키워드를 사용할 때는 미디어 유형을 필수로 지정해야합니다.

미디어 기능 특정

사용자, 출력 장치, 주변 환경 특징을 설명합니다.

@media (hover: hover) { ... }

@media (max-width: 1024px) { ... }

첫 번째 쿼리는 마우스가 호버할 수 있으면 스타일을 적용합니다. css를 많이 사용해본 것은 아니지만, 대부분 이러한 기능을 사용할 때 주료 max-width와 같은 범위 기능을 주로 사용한 것 같습니다.

특정 기능이 현재 브라우저에 적용되지 않으면, 해당 미디어 기능을 포함한 표현식은 항상 거짓입니다.

유형과 기능을 연산자로 조합하기

미디어의 유형과 미디어 기능을 논리 연산자로 조합해서 다양하게 사용할 수 있습니다.

@media screen and (max-width: 1024px) { ... }

기본적으로 반응형에 이용하기 위해서 많이 사용하는 쿼리 입니다. 나눠서 보면 미디어 유형으로 screen, 미디어 기능으로 max-width: 1024px, 논리 연산자로 and가 포함되어 있습니다.

풀어서 해석하면 주로 화면이 대상인 미디어의 넓이가 1024px인 장치라고 이해할 수 있습니다.

@media not all and (monochrome) { ... }

not 연산자는 미디어 쿼리 전체의 의미를 반전시킵니다. (Level 3 모듈 기준) @media not (all and (monochrome)) { ... }와 동일한 의미를 가지게 됩니다.

@media not screen and (color), print and (color) { ... }

하지만 쉼표(,)가 포함되어 있다면, 다른 방식으로 반전이 됩니다. 쉼표를 기준으로 쿼리를 구분짓기 때문에 해당 미디어 쿼리는 not screen and (color)와 print and (color) 두 개의 쿼리로 구분짓게 됩니다. 기본적으로 not은 쿼리 전체를 부정하게 됩니다. (Level 4 제외) 이러한 경우 @media not (screen and (color)), print and (color) { ... } 동일하게 해석이 됩니다.

Level 4의 구문 향상

범위 지정

미디어 쿼리 Level 4는 향상된 기능을 제공하는데, 대표적으로 미디어쿼리가 '범위' 유형을 가진 기능을 사용할 수 있습니다.

자주 사용하던 @media (max-width: 1024px) { ... }와 같은 쿼리는 Level 4에서는 @media (width <= 1024px) { ... }와 같이 사용할 수 있습니다. max-, min-과 같은 키워드를 사용하지 않고 범위로 지정할 수 있습니다.

not으로 기능 부정

Level 3 모듈까지는 쿼리 전체를 부정할 수 있었는데, 기능을 부정할 수 있습니다.

@media (not(hover)) { ... }

hover를 할 수 없는 장치를 사용할 때 not(hover)를 사용할 수 있습니다.

or로 다수의 기능 판별

다수의 기능 가운데 하나라도 있는지 테스트해서 그 중에 하나라도 참이라면 true를 반환할 수 있습니다.

@media (not (color)) or (hover) { ... } 

해당 쿼리의 의미는 컬러화면이 아니거나 hover 기능이 지원이 되지 않을 때를 의미합니다.

개인적으로 쉼표와 조금 헷갈렸는데요.. 🤯 쉼표(,)는 다수의 미디어 쿼리를 하나의 규칙으로 조합하는게 포인트입니다. 쿼리로 구분짓지 않고, 하나의 쿼리에 다수의 기능을 작성할 때는 or을 사용하는 것이 좋아보입니다.

미디어쿼리 Level 4 사앙에는 상당수의 최신 브라우저를 지원하지만, 몇몇 미디어 기능들은 잘 지원되지 않습니다.

마무리

사실 이전부터 only라는 키워드를 왜 써야하지?🤔라는 생각을 하면서 그냥 복사, 붙여넣기 식으로 많이 사용했던 것 같습니다. 마냥 반응형이라고 하면 @media only screen and (min, max-width: ...) { ... }와 같은 쿼리만 입력하고 breakpoint만 넣어뒀으니까요.. 🤣

Leve 4라는 구분점이 있는지도 오늘 처음 알았습니다.. ㅎㅎ MDN의 미디어 쿼리 사용하기 페이지를 한 번 쭉 보았는데요!

오늘도 제대로 된 이유를 모르고 사용하던 기능을 알게 되서 만족스럽습니다 👍

출처

• https://developer.mozilla.org/ko/docs/Web/CSS/CSS_media_queries/Using_media_queries#%ea%b5%ac%eb%ac%b8

회사에서 주로 모바일 웹앱으로 작업을 하다가 새로운 프로젝트를 작업하게 됐는데요. 반응형 웹으로 작업을하고 초기세팅까지 하려고 하니 익숙하지 않은 부분이 많았습니다 😢

Global Style 적용하기

emotion에서 제공하는 Global 컴포넌트를 이용해서 적용할 수 있습니다.

styles/ 디렉터리를 생성한 뒤 Global.tsx 파일을 생성합니다. 그리고 아래와 같이 코드를 작성해줍니다.

// Global.tsx
import { Global, css } from '@emotion/react'

const style = css`
    html,
    body {
        margin: 0;
        padding: 0;
        font-size: 16px;
    }
`

const GlobalStyle = () => <Global styles={styles} />

export default GlobalStyle

해당 파일에 리셋과 관련된 css를 포함해도 좋다고 생각합니다. 최근에는 reset.css와 normalize.css를 섞어서 사용하거나 사용성에 맞게 사용하는 추세라고 합니다.

이후 pages/_app.tsx 에서 해당 Global Style을 적용합니다.

// _app.tsx
import { GlobalStyle } from '@/styles/Global'

const App = ({ Component, pageProps }) => {
    return (
        <Layout>
            <GlobalStyle />
            <Component {...pageProps} />
        </Layout>
    )
}

reset과 normalize 웹 브라우저(chrome, fireforx 등)마다 기본적으로 제공하는 스타일이 다르게 적용되어 있습니다. 브라우저 별로 일관된 스타일을 제공해야 되는 입장으로 이러한 기본적인 스타일을 초기화(reset)하거나 동일하게 유지(normalize)할 필요가 있습니다.

ThemeProvider 적용하기

다크모드나 사용자 테마를 적용하기 위해서 사용되는 컴포넌트입니다. emotion에서 제공하는 ThemeProvider 컴포넌트를 이용해서 적용할 수 있습니다.

styles/ 디렉터리에서 theme.ts 파일을 생성합니다.

// theme.ts
import { Theme } from '@emotion/react'

const theme: Theme = {
    color: {
        black: '#000',
        white: '#fff',
    }
}

export default theme

이후 pages/_app.tsx에서 테마를 적용합니다.

// _app.tsx
import { GlobalStyle } from '@/styles/Global'
import { ThemeProvider } from '@emotion/react'
import theme from '@/styles/theme'

const App = ({ Component, pageProps }) => {
    return (
    <ThemeProvider theme={theme}>
        <Layout>
            <GlobalStyle />
            <Component {...pageProps} />
        </Layout>
    </ThemeProvider>
    )
}

SerializedStyles 활용하기

반응형 컴포넌트나 레이아웃 사용하기 위해서는 media query와 breakpoint를 피할 수 없는데요. emotion에서 제공하는 SerializedStyles를 이용해서 조금 더 간편하게 반응형을 사용할 수 있습니다.

media query를 컴포넌트처럼 분리해서 사용하는 방식입니다. styles/ 디렉터리에 mediaQuery.ts 파일을 생성합니다.

//mediaQuery.ts
import { SerializedStyles, css } from '@emotion/react'

const breakPoints = {
    desktop: 1920,
    tablet: 1439,
    mobile: 767,
}

export const MobileStyle = (style: SerialzedStyles) => css`
    @media screen and (max-width: ${breakPoints.mobile}px) {
        ${style}
    }
`

Emotion Composition의 기능을 이용해서 구현합니다. Emotion Composition은 두 개 이상의 스타일 객체를 결합하여 새로운 객체를 생성합니다. css 스타일을 넘겨주고 media query가 적용된 스타일을 내보내는 모듈 역할을 합니다.

// styles.ts

import styled from '@emotion/styled'

export const Container = styled.div`
    width: 100%;

    ${MobileStyle(css`
        font-size: 1.5rem;
        font-weight: 700;
    `)}
`

매번 media query와 breakpoint를 가져와서 사용하는 것이 아니기 때문에 중복 코드를 줄일 수 있습니다.

마무리

최근에 새로운 프로젝트를 진행하면서 처음 써보는 Next.js와 여러 라이브러리들에 대한 정리를 제대로 하지 못한 것 같습니다. 😭 최근에 Next.js를 비롯해서 ReactQuery, React-Hook-Form 등 처음 사용해보는 기술 및 도구들이 많아졌습니다.. 출시 기간에 맞추다보니 이해하지 않고 사용하는 부분들이 많았는데, 이렇게 하나씩 정리하면서 이해하고 사용하는 개발자가 됐으면 합니다.. 🙏

출처

• https://emotion.sh/docs/globals
• https://velog.io/@moon_l/Next.js-Emotion-%EA%B8%80%EB%A1%9C%EB%B2%8C-%EC%8A%A4%ED%83%80%EC%9D%BC-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0
• https://mine-it-record.tistory.com/598
• https://hailey0930.github.io/css/2023/04/17/CSS_refactoring/#/
• https://emotion.sh/docs/composition

기본적으로 타입스크립트로 언어를 설정하고 CRA를 통해서 프로젝트를 생성했다면 typescript-eslint를 사용하면 됩니다.

전체적인 플로우는

1. typescript-eslint와 관련된 라이브러리 설치 및 .eslintrc.js 파일 설정
2. prettier 라이브러리 설치
3. prettier와 eslint를 같이 사용할 수 있는 라이브러리 설치 및 .eslintrc.js 파일 설정
4. 본인 기호에 맞게 .prettierrc.js 파일 설정

typescript-eslint

타입스크립트 코드를 linting해주는 도구입니다. eslint와 typescript는 각자의 parser를 통해서 서로 다른 AST(Abstract Syntax Tree)를 만들어 내는데, 이렇게 다른 AST로 인해 생겨나는 문제점을 해결하기 위해서 생겨난 도구입니다.

typescript-eslint를 통해 eslint와 typescript가 함께 사용할 수 있게 됐습니다.

ESLint 설정

ESLint

• ESLint는 ES와 Lint의 합성어
• ECMA Script + Lint로써 표준 자바스크립트 문법에서 에러를 표시해주는 도구
• 버그를 사전에 방지, tab이나 줄바꿈 등의 코딩 스타일을 정의함으로써 협업에 도움이 된다.

ESLint 관련 라이브러리 설치

yarn add --dev eslint

eslint@8.22.0 버전에 대한 문제가 생긴다면 아래의 명령어로 라이브러리를 설치하면 됩니다.

yarn add --dev eslint@8.22.0 --save-exact

typescript-eslint 관련 라이브러리 설치

yarn add --dev @typescript-eslint/eslint-plugin @typescript-eslint/parser

@typescript-eslint/parser

• 타입스크립트 코드에 대한 AST 생성

@typescript-eslint/eslint-plugin

• typescript-eslint의 규칙들을 사용할 수 있게 해준다.

.eslintrc.cjs 설정

module.exports = {  
    root: true,
    // eslint에 어떠한 parser를 사용할지 알려주는 옵션
    // eslint가 typescript 문법을 이해할 수 있게 해준다.
    parser: '@typescript-eslint/parser',
    // typescript-eslint에서 제공하는 규칙들을 사용할 수 있게 해준다.
    plugins: ['@typescript-eslint'],  
    // 어떠한 규칙들과 설정으로 eslint를 사용할지 명시한다.
    // 아래와 같이 작성하면 default 값으로 적용이 된다.
    extends: [
        'eslint:recommended',
        'plugin:@typescript-eslint/recommended',
    ],

    rules: {
        // 세미콜론이 없으면 에러로 취급한다.
        semi: 'error',
        // 기존 프로젝트에서는 'warn'으로 취급되지만, 'error'로 설정하면 에러로 취급한다.
        '@typescript-eslint/no-unused-vars': 'error'
    }
};

만약 프로젝트에서 ESM을 사용할 수 없다면 .eslintrc.js로 파일명을 사용하면 됩니다.

.eslintignore 파일 작성

eslint를 적용하지 않을 파일이나 폴더를 적어줍니다.

// .eslintignore
node_modules
dist

Linting 방법

yarn eslint . --ext .js,.jsx,.ts,.tsx
npx eslint . --ext .js,.jsx,.ts,.tsx

Prettier 설정

Prettier

• 정해진 규칙에 따라 자동으로 코드 스타일을 정리해주는 도구
• 여러 규칙들을 쉽게 커스터마이징 할 수 있다.

prettier는 코드 포맷팅에 특화되어 있으므로 eslint가 할 수 없는 최대 글자 길이에 맞춘 자동 포맷팅을 할 수 있다.

Prettier 관련 라이브러리 설치

yarn add --dev prettier

추가적으로 각자 사용하는 IDE에서 prettier를 설정해주면 됩니다!

Prettier와 ESLint를 동시에 사용하기

prettier와 eslint를 동시에 사용하는 방법은 여러가지 방법이 있습니다.

1. prettier-eslint

• prettier를 실행 후 eslint를 실행하는 방법
• prettier-eslint 메인테이너도 2017년 이미 이 패키지를 사용하지 않는다.

2. eslint-config-prettier

• eslint에서 prettier와 충돌하는 eslint 규칙을 전부 꺼주는 방법
• 코드 오류를 잡는데는 eslint를 코드 포맷팅에는 prettier를 사용하는 방법이다.
• 두 개의 역할을 구분하는 것이 좋으므로 이 방법을 추천한다.

라이브러리 설치

yarn add --dev eslint-config-prettier

.eslintrc.cjs 파일 수정

{
  "extends": [
    "some-other-config-you-use",
    // prettier 추가
    "prettier"
  ]
}

prettier/@typescript-eslint는 eslint-config-prettier v8.0.0에서 지워졌다. 그렇기 때문에 eslint-config-prettier 버전이 8이상이라면 prettier/@typescript-eslint를 지우면 됩니다.

3. eslint-plugin-prettier

• 린터인 것처럼 prettier를 실행하는 플러그인
• 특정 상황에서 유용할 수 있지만, prettier를 직접 실행하는 것보다 느리다.
• 포맷팅 문제도 오류로 출력되어서 오류 메시지가 지나치게 많다.

라이브러리 설치

yarn add --dev eslint-plugin-prettier

.eslintrc.cjs 파일 수정

module.exports = {  
 root: true,  
 parser: '@typescript-eslint/parser',  

    // prettier 추가
 plugins: ['@typescript-eslint', 'prettier'],  
 extends: [  
  'eslint:recommended',  
  'plugin:@typescript-eslint/recommended',  
  // prettier 삭제
  // 'prettier' 

  // plugin:prettier/recommended 추가
  'plugin:prettier/recommended'  
 ],  

 rules: {
    //prettier/prettier rule 추가
  'prettier/prettier': 'error',    
  semi: 'error',  
  '@typescript-eslint/no-unused-vars': 'error',  

 }  
};

해당 방법은 eslint-config-prettier 라이브러리와 같이 사용하는 방법입니다. eslint-plugin-prettier를 제대로 사용하기 위해서는 formatting에 관련한 모든 eslint 규칙을 꺼야합니다. 그러지 않으면 에러가 발생하게 됩니다.

그래서 공식문서에서도 formatting에 관련한 모든 eslint 규칙을 비활성화하기 위해서 eslint-config-prettier 설치를 하나의 솔루션으로 제공하고 있습니다.

해당 방식을 통해서 eslint만 이용해서 문법 검사와 formatting을 함께 실행시킬 수 있습니다. 하지만 prettier를 직접 실행하는 것보다 속도가 느리고 오류 메시지가 지나치게 많다는 단점도 있기 때문에 선호하는 방식으로 사용하면 될 것 같습니다!

.prettierrc.js 파일 설정

//.prettierrc.js  

module.exports = {  
  // 문자열은 따옴표로 formatting
  singleQuote: true,  
  //코드 마지막에 세미콜른이 있게 formatting
  semi: true,  
  //탭의 사용을 금하고 스페이스바 사용으로 대체하게 formatting
  useTabs: false,  
  // 들여쓰기 너비는 2칸  
  tabWidth: 2,  
  // 코드 한줄이 maximum 80칸  
  printWidth: 80,  
};

출처

• https://typescript-eslint.io/getting-started
• https://stackoverflow.com/questions/65675771/eslint-couldnt-find-the-config-prettier-typescript-eslint-after-relocating
• https://gingerkang.tistory.com/97
• https://velog.io/@_jouz_ryul/ESLint-Prettier-Airbnb-Style-Guide%EB%A1%9C-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0#22-eslint-config-prettier--eslint-plugin-prettier

Next.js의 pageExtensions 기능을 통해서 index.page.tsx와 같은 형식으로 페이지를 표현할 수 있습니다!

pageExtensions는 next.config.json 옵션 중 하나로 특정 형식의 이름을 페이지로 인식하는 기능입니다. 이렇게 사용하는 이유는 페이지 디렉터리 안에서 페이지 파일을 구분하기 위해서 입니다!

스타일을 별도의 ts나 tsx로 관리하게 된다면, 해당 파일을 페이지로 인식하게 됩니다. 추가적으로 테스트 파일이나 별도의 컴포넌트 파일을 가지게 된다면 해당 파일도 페이지로 인식하게 됩니다. 😢

저의 경우에는 styles.ts 파일로 스타일을 관리하는데요. 아직 테스트 코드는 작성하고 있지 않지만, 테스트 코드도 추가하게 된다면, 더더욱 페이지 파일을 구분해야 할 것 같습니다.

공식 문서

pageExtensions

Next.js에서 사용 중인 기본 페이지 확장자(.tsx, ts, jsx, js)을 확장할 수 있습니다. next.config.js 파일 안에 pageExtensions 설정을 추가합니다.

module.exports = {
  pageExtensions: ['mdx', 'md', 'jsx', 'js', 'tsx', 'ts'],
};

위의 값을 변경하게 되면 Next.js의 아래를 포함한 모든 페이지에 영향이 가게 됩니다.

• middleware.js
• pages/_document.js
• pages/_app.js
• pages/api/

예를 들어, .ts 페이지 확장자를 .page.ts로 재설정하게 된다면, _app.page.ts와 같이 페이지들의 이름을 수정해야 합니다.

Including non-page file in the pages directory

테스트 파일이나 컴포넌트로 사용되는 다른 파일들을 pages 디렉터리에 같이 배치할 수 있습니다. 이러한 경우에는 next.config.js 파일 안에 pageExtensions 설정을 추가합니다.

module.exports = {
  pageExtensions: ['page.tsx', 'page.ts', 'page.jsx', 'page.js'],
};

그리고, 페이지의 이름을 .page가 포함된 파일명으로 바꿔줍니다. (예를 들어 MyPage.tsx를 MyPage.page.tsx로 이름을 바꿔줍니다.) 위에 언급된 파일들을 포함해서 모든 Next.js 페이지의 이름을 변경해야 합니다.

마무리

공식문서를 확인하기 전에는 Next.js가 페이지를 구분하기 위한 기능이라고 생각하기 보다는 개발자의 가시성을 위한 기능이라고 생각했습니다. ㅎㅎ

스타일 코드 및 테스트 코드를 작성하다 보면 pages 디렉터리 안에 페이지 파일만 존재하는 것은 쉽지 않으니.. 앞으로 해당 확장자를 잘 활용해서 Next.js가 페이지 파일을 잘 구분할 수 있도록 해야 할 것 같습니다.

출처

• https://nextjs.org/docs/pages/api-reference/next-config-js/pageExtensions

사실 이론편이라기 보다는 ESLint의 공식문서의 일부를 번역한 내용입니다! 실제로 eslint-config를 만들기 위해서는 더 다양한 부분을 이해할 수 있어야할 것 같습니다. 다른 eslint-config나 eslint-plugin을 가져와서 사용하는 부분에 대한 설명도 없고, 어떻게 만들 수 있는지에 초점을 두는 문서이기 때문이죠.

그래도 기본적으로 eslint-config를 만들기 위한 최소 규칙? 정도라고 이해해주시면 될 것 같습니다.

오늘은 많은 분들이 사용하시는 airbnb 관련 plugin과 config를 이용해서 나만의 eslint-config를 만들어보려고 합니다! 개인적으로 React, Next, React Native와 관련된 프로젝트를 주로 진행하기 때문에 airbnb 컨벤션을 선호합니다.

너무 깊게 ESLint를 설정하지 않는다면, 이정도의 설정으로도 충분히 ESLint를 잘 활용할 수 있다고 생각합니다.

만약 본인이 ESLint의 plugin, config의 차이, extends, rule, recommended와 같은 키워드를 모르신다면, 정말 리얼 마지막 ESLint 사용법 뿌시기 포스팅을 한 번 보시고 오시는 것을 추천드립니다. 🙏

프로젝트 세팅

mkdir eslint-config-mytool
cd eslint-config-mytool
yarn init

// package.json
{
  "name": "eslint-config-mytool",
  "version": "0.1.0",
  "description": "My ESLint Custom Config",
  "main": "index.js",
  "license": "MIT"
}

명령어를 따라가다 보면 위와같은 package.json 파일이 생성되게 됩니다.

라이브러리 이름은 eslint-config가 포함되어야 합니다. 이름에 대한 규칙은 ESLint에서 정한 규칙입니다.

라이브러리 만들기

eslint-config 라이브러리를 만드는 방식은 한 가지만 있는 것은 아닙니다. 오늘 사용하는 방법은 여러 방법 중 하나라고 생각해주시면 감사하겠습니다. 🙏

airbnb의 eslint-config 라이브러리는 크게 eslint-config-airbnb, eslint-config-airbnb-base로 나뉩니다! javascript만 사용한다면, eslint-config-airbnb-base를 사용하는 것을 권장합니다.

airbnb-base 설정

import, es6, node, variables와 같은 설정이 포함되어 있습니다.

라이브러리 설치

yarn add --dev eslint eslint-config-airbnb-base

index.js 파일 작성

// index.js
module.exports = {  
  env: {  
    es2021: true,  
    node: true,  
    browser: true,  
  },  
  extends: ["eslint:recommended", "airbnb-base"],  
  parserOptions: {  
    ecmaVersion: 12,  
    sourceType: "module",  
  },  
  rules: {  
    // custom rules  
  }  
};

위와 같이 설정하면 eslint-config-mytool 라이브러리는 eslint-config-airbnb-base와 동일한 역할을 하는 라이브러리가 됐습니다!

react 설정

여기서 react와 관련된 설정을 추가하려면 어떻게 해야할까요?

라이브러리 설치

yarn add --dev eslint-config-airbnb \
               eslint-plugin-import \
               eslint-plugin-jsx-a11y \
               eslint-plugin-react \
               eslint-plugin-react-hooks

eslint-config-airbnb 이후의 설치되는 라이브러리들은 모두 eslint-config-airbnb에서 필요한 의존성들입니다. eslint-config-airbnb만 설치했을 때 react와 관련된 설정을 사용할 수 없습니다.

react.js 파일 작성

module.exports = {  
  extends: ["plugin:react/recommended", "airbnb", "airbnb/hooks"],  
  plugins: ["react"],  
  parserOptions: {  
    ecmaFeatures: {  
      jsx: true,  
    },  
  },  
  rules: {  
    // custom rules  
  },  
};

위와 같이 작성하면 react와 관련된 설정도 추가해서 사용할 수 있습니다.

typescript 설정

라이브러리 설치

yarn add -dev eslint-config-airbnb-typescript \
              @typescript-eslint/eslint-plugin \
              @typescript-eslint/parser

typescript.js 파일 작성

module.exports = {  
  parser: "@typescript-eslint/parser",  
  parserOptions: {  
    project: ["./tsconfig.json"],  
  },  
  plugins: ["@typescript-eslint"],  
  extends: [  
    "plugin:@typescript-eslint/eslint-recommended",  
    // airbnb-typescript
    "airbnb-typescript/base",
    // airbnb-typescript + react
    "airbnb-typescript",  
  ],  
};

eslint-config-airbnb-base와 같이 react 설정을 포함하지 않아도 될 때는 extends에서 airbnb-typescript/base로 설정을 추가하면 됩니다.

별도의 파일을 생성하지 않고 index.js 파일에 위의 모든 설정을 한 번에 넣어도 상관없습니다. 크게 확장성을 고려하지 않는다면, index.js 파일에서 한 번에 관리하는 것도 좋아보입니다. 👍

package.json 파일 및 디렉터리 구조

{  
  "name": "eslint-config-mytool",  
  "version": "0.1.0",  
  "description": "My ESLint Custom Config",  
  "main": "index.js",  
  "license": "MIT",  
  "dependencies": {  
    "eslint-config-airbnb-base": "^15.0.0",  
    "eslint-config-airbnb": "^19.0.4",  
    "eslint-config-airbnb-typescript": "^17.0.0"  
  },  
  "devDependencies": {  
    "@typescript-eslint/eslint-plugin": "^5.59.2",  
    "@typescript-eslint/parser": "^5.59.2",  
    "eslint": "^8.40.0",  
    "eslint-config-airbnb": "^19.0.4",  
    "eslint-config-airbnb-base": "^15.0.0",  
    "eslint-config-airbnb-typescript": "^17.0.0",  
    "eslint-plugin-import": "^2.27.5",  
    "eslint-plugin-jsx-a11y": "^6.7.1",  
    "eslint-plugin-react": "^7.32.2",  
    "eslint-plugin-react-hooks": "^4.6.0",  
    "prettier": "^2.8.8"  
  },  
  "peerDependencies": {  
    "@typescript-eslint/eslint-plugin": "^5.59.2",  
    "@typescript-eslint/parser": "^5.59.2",  
    "eslint": "^8.40.0",  
    "eslint-plugin-import": "^2.27.5",  
    "eslint-plugin-jsx-a11y": "^6.7.1",  
    "eslint-plugin-react": "^7.32.2",  
    "eslint-plugin-react-hooks": "^4.6.0"  
  }  
}

eslint-config-mytool
├─ node_modules/
├─ index.js
├─ react.js
├─ typescript.js
└─ package.json

ESLint에서는 peerDependencies를 명시해주는 것을 권장합니다. eslint와 플러그인의 버전마다 추가 된 규칙이나 옵션이 있기 때문에 설정한 규칙을 지원하는 버전을 명시해주는 것이 좋다고 합니다.

배포하기

npm publish

배포하기 전 어느정도의 과정이 필요합니다. NPM 배포에 대한 내용은 생략하도록 하겠습니다.

사용하기

yarn add --peer --dev eslint-config-mytool
yarn add --dev eslint-config-mytool

--peer 명령어를 통해서 eslint-config-mytool에서 명시한 peerDependency를 같이 설치하게 됩니다.

default

// .eslintrc.json
{  
  "extends": ["eslint-config-mytool"],  
  "rules": {  
    // custom rules  
  }  
}

react

{  
  "extends": ["eslint-config-mytool", "eslint-config-mytool/react"]  
}

typescript

{  
  "extends": ["eslint-config-mytool", "eslint-config-mytool/typescript"]  
}

위와 같이 필요한 설정들을 extends 필드에 추가해서 사용하면 됩니다. 라이브러리에서 custom rule을 관리해도 되고 프로젝트의 .eslintrc 파일에서 rules를 관리하셔도 됩니다!

마무리

개인 프로젝트를 많이 하는 것은 아니지만, Lint에 관심이 생기다 보니 위와 같이 만들어보는 작업을 경험해서 좋았습니다! 🤩

회사에서는 개발하느라 바쁘고, 이 부분을 이정도까지 신경써야 하는가? 라는 생각도 했었는데요. 처음 개발을 시작할 때를 생각해보면 요즘 저는 꽤나 많이 협업과 도구에 대한 관심이 생긴 것 같습니다.😎 회사의 여러 프로젝트에 동일한 포맷팅과 컨벤션을 제공할 수 있다는 것은 꽤나 매력적인 것 같습니다. ㅎㅎ

처음에 이 작업을 할 때, ESLint의 룰도 하나씩 만져보면서 개인 혹은 조직에 맞는 라이브러리를 만들어보고 싶었습니다. 하지만 모든 룰들을 확인하면서 규칙들을 적용하는 것은 꽤나 많은 시간이 소요되는 일이었습니다. 😭

왜 사람들이 기존의 컨벤션으로 되어있는 것을 커스텀해서 사용하는지 알게 되었습니다. ㅎㅎ

차라리 이 시간에 해야할 것들과 하고 싶은 것들을 하는 것이 더 가치있다고 생각해서 제일 유명한 컨벤션 라이브러리를 참고해서 나만의 eslint-config 라이브러리를 만들어 보았습니다.

출처

• https://github.com/airbnb/javascript/tree/master/packages/eslint-config-airbnb-base/rules
• https://github.com/iamturns/eslint-config-airbnb-typescript
• https://github.com/ridi/eslint-config
• https://caferion.netlify.app/frontend/eslint-rule-setting/

공유 환경설정 (Share Configurations)

ESLint Configuration을 공유하기 위해서는, 공유 가능한 config를 만들어야 합니다. 공유 가능한 config를 NPM에 배포할 수 있으며, 다른 사용자들이 배포된 config를 다운로드하고 사용할 수 있습니다.

이 페이지는 어떻게 공유 가능한 config를 만들고 배포하는지 설명합니다.

공유 가능한 config 생성 (Creating a Shareable Config)

공유 가능한 config는 환경설정 객체를 가져오는(export) 간단한 NPM 패키지입니다. 시작하기 앞서서, 평소처럼 Node.js 모듈을 만들어봅시다.

해당 모듈의 이름은 다음 중 하나의 양식을 따라야 합니다.

• eslint-config로 시작해야 합니다. 예를 들면 eslint-config-myconfig로 작성할 수 있습니다.
• npm scpoed 모듈입니다. scoped 모듈을 생성하려면, 모듈의 이름 또는 접두사를 @scope/eslint-config로 지정합니다. @scope/eslint-config 혹은 @scope/eslint-config-myconfig 처럼 사용할 수 있습니다.

모듈 안에서, 공유 가능한 config에서 모듈의 메인 진입점 파일(main entry point file)을 가져옵니다. (export) 기본적으로 메인 진입점 포인트 파일은 index.js 파일입니다.

예를 들면

// index.js
module.exports = {

    globals: {
        MyGlobal: true
    },

    rules: {
        semi: [2, "always"]
    }

};

index.js 파일은 자바스크립트이기 때문에, 파일에서 이 설정들을 읽어올 수 있고 동적으로 생성할 수 있습니다.

공유 가능한 config 배포

공유 가능한 config가 준비 되었을 때, 다른 사람과 공유할 수 있게 NPM에 배포할 수 있습니다. package.json 파일 안에 eslint, eslintconfig와 같은 keywords를 사용하는 것을 권고합니다. 다른 사용자들이 쉽게 해당 모듈을 찾을 수 있습니다.

package.json 파일 안에 peerDependencies 필드를 이용해서 ESLint 의존성을 선언할 수 있습니다. 호환성을 고려하면서 의존성을 선언할 때 추천하는 방식은 >=와 같은 범위 구문을 사용하는 것입니다.

예를 들면

{
    "peerDependencies": {
        "eslint": ">= 3"
    }
}

만약 공유 가능한 config가 어떠한 플러그인에 의존하고 있다면, 그것 또한 peerDependency로 지정해야 합니다. (플러그인은 최종 사용자의 프로젝트에서 사용되는 것과 관련이 되어 있으므로, 최종 사용자는 필요한 플러그인을 설치해야 합니다.)

그러나, 만약 공유 가능한 config가 커스텀 parser에 의존하고 있거나 다른 공유 가능한 config에 의존하고 있다면 이러한 패키지들은 package.json 파일 안에 있는 dependencies 필드에 지정할 수 있습니다.

공유 가능한 config를 배포하기전에 컴퓨터에서 linking을 이용해서 테스트 해볼 수 있습니다.

npm link

그 다음에, 공유 가능한 config를 사용하려고 하는 프로젝트에서 명령어를 입력합니다.

npm link eslint-config-myconfig

직접 진행할 때는 eslint-config-myconfig를 모듈의 실제 이름으로 변경하세요.

공유 가능한 config 사용

공유 가능한 config를 사용할 때, 설정 파일의 extends 필드 안에 해당 config 이름을 포함해야 합니다. 모듈 이름을 작성합니다.

예를 들면

{
    "extends": "eslint-config-myconfig"
}

eslint-config를 생략할 수 있습니다. ESLint에 의해 자동적으로 추정됩니다.

{
    "extends": "myconfig"
}

공유 가능한 config는 ESLint CLI --config 플래그와 같이 사용할 수 없습니다.

NPM Scoped Modules

NPM의 scoped 모듈 또한 여러 방식을 지원합니다.

모듈 이름을 사용할 수 있습니다.

{
    "extends": "@scope/eslint-config"
}

eslint-config를 생략할 수 있습니다.

{
    "extends": "@scope"
}

모듈의 이름은 커스터마이징할 수 있습니다. 예를 들어서 패키지의 이름이 @scope/eslint-config-myconfig라면, 아래와 같이 명시할 수 있습니다.

{
    "extends": "@scope/eslint-config-myconfig"
}

또한 eslint-config를 생략할 수 있습니다.

{
    "extends": "@scope/myconfig"
}

공유 가능한 config의 설정 오버라이딩

.eslintrc 파일을 통해서 공유 가능한 config의 설정들을 오버라이딩할 수 있습니다.

여러 config 공유

여러 config들을 하나의 NPM 패키지에서 공유할 수 있습니다. 공유 가능한 config 생성(Creating a Shareable Config) 섹션에 패키지의 기본 config가 명시되어 있습니다. NPM 패키지에 새로운 파일을 추가함으로써 추가적인 config를 명시할 수 있습니다. 그리고 추가한 config를 참조할 수 있습니다.

예를 들어서, NPM 패키지에 my-sepcial-config.js라고 불리는 파일을 생성할 수 있습니다. 그리고 해당 config도 export 할 수 있습니다.

// my-special-config.js
module.exports = {
    rules: {
        quotes: [2, "double"]
    }
};

그리고 나서, 당신이 사용하고 있는 패키지 이름이 eslint-config-myconfig라고 가정했을 때 추가적인 config를 접근할 수 있습니다.

{
    "extends": "@scope/eslint-config/my-special-config"
}

파일 이름에서 .js을 분리해서 사용할 수 있습니다.

중요! 에러를 방지하기 위해서 plugin 안에는 항상 default config를 포함하고 있는 것을 강력하게 권장합니다.

Local Config File Resolution

만약 각기 다른 디렉터리에 있는 config에 서로 확장이 가능한 config 생성이 필요하다면, 필요한 내용을 조작할 수 있는 하나의 공유 가능한 config를 만들 수 있습니다.

예를 들어서, 사용하는 패키지 이름을 eslint-config-myconfig라고 가정하고, 해당 패키지는 아래의 구조를 가지고 있습니다.

myconfig
├── index.js
└─┬ lib
  ├── defaults.js
  ├── dev.js
  ├── ci.js
  └─┬ ci
    ├── frontend.js
    ├── backend.js
    └── common.js

index.js 파일에서는 아래와 같이 config 파일을 export 할 수 있습니다.

module.exports = require('./lib/ci.js');

패키지 안에는 아래와 같은 내용을 담고 있는 /lib/defaults.js 파일이 있습니다.

module.exports = {
    rules: {
        'no-console': 1
    }
};

/lib/ci.js 파일 안에는

module.exports = require('./ci/backend');

/lib/ci/common.js 안에는

module.exports = {
    rules: {
        'no-alert': 2
    },
    extends: 'myconfig/lib/defaults'
};

config 파일의 모든 extends 키워드에 확장하고 싶은 파일의 절대경로(full package path)를 사용함으로써 확장을 할 수 있습니다.

/lib/ci/backend.js 내용

module.exports = {
    rules: {
        'no-console': 1
    },
    extends: 'myconfig/lib/ci/common'
};

/lib/ci/backend.js 파일을 보면 config를 적절하게 사용하려면 패키지의 전체 경로를 포함해야 하는 것을 다시 한 번 확인할 수 있습니다.

마무리

새로운 라이브러리 혹은 프레임워크, 언어를 배우면서 공식문서를 제대로 번역해본적이 없었는데요! 최근 ESLint 내용을 계속해서 찾아보다보니, 공식문서를 한 번 번역해보고 싶다는 생각이 들었습니다! 📖

그래서 모든 문서를 다 번역하는 것은 어렵지만, 한 페이지 정도는 빠르게 할 수 있지 않을까? 라는 생각에 도전하게 되었습니다! 그래도 다른 포스팅과 문서들을 찾아보고 공식문서를 보니 어떠한 의미로 설명되었는지 조금 더 쉽게 이해가 됐던 것 같습니다!

그래도 언제나 그렇듯.. 영어는 어려운 것 같습니다 🤦‍♂️

출처

• https://eslint.org/docs/latest/extend/shareable-configs#creating-a-shareable-config

이전에 @typescript-eslint와 prettier를 설정한 적이 있습니다. prettier는 코드 포맷팅을 하기 위한 라이브러리이기 때문에 크게 설정할 내용이 없었는데요. eslint의 경우에는 문제가 있었습니다.

eslint를 강하게 사용할 수 없다 💪

저는 기존에 CRA을 이용해서 프로젝트를 생성했었습니다.

기본적으로 typescript도 사용하고 있었습니다. CRA로 생성하게 되면 프로젝트를 실행, 수정할 때마다 컴파일이 새롭게 되고 lint 검사도 같이 진행하게 됩니다.

그런데 만약 eslint 설정에서 no-console을 error로 정의하게 되면 어떨까요? 콘솔을 찍어보기 위해서 작성한 console.log() 명령어를 error가 됩니다.

그렇다고 no-console을 error로 정의하지 않고 그대로 사용한다면, 배포했을 때 console.log() 명령어가 배포된 프로젝트에 반영될 수 있는 상황을 나올 수 있습니다.

결국 어떠한 조치를 하지 않으면, eslint를 제대로 활용하고 있지 않다라는 생각이 들었습니다.

혹시 위의 내용을 더 쉽게 풀어나갈 수 있는 방법이 있다면 공유해주시면 감사하겠습니다 🙏

그렇다면lint 검사를 하지 않는다.

CRA에서 제공하는 eslint 검사를 자동으로 하지 않게 설정하는 것입니다. 그리고 git hook을 이용해서 특정 시점에 lint 검사를 할 수 있도록 하는 것이죠!

저는 craco 라이브러리를 사용하고 있기 때문에 craco.config.js 파일을 수정했습니다. 아래와 같이 enable을 false로 설정하면 자동으로 lint 검사하는 설정을 끌 수 있습니다.

module.exports = {
    eslint: {
        enable: false,
    }
}

eslint 룰 수정하기 ✏️

모든 eslint 룰을 다 나열할 수는 없지만, no-console, no-empty 와 같이 불필요한 코드를 사용하지 않게 해주는 룰을 추가했습니다.

다양한 룰들을 설정할 수 있으니 @typescript-eslint, eslint 페이지에 들어가셔서 본인에게 맞는 룰들을 추가하면 좋을 것 같습니다.

git hook을 통한 lint 검사

이미 git은 특정 상황에서 스크립트를 실행할 수 있도록 hook이라는 기능을 지원하고 있습니다! 별도로 설치할 필요도 없고, git으로 관리되고 있는 폴더에서 cd .git/hooks/ 명령어를 입력하고 ls 명령어를 입력하면 git이 제공하는 특정 상황을 볼 수 있습니다.

하지만 아쉽게도 git hook은 원격으로 저장하고 관리할 수 없습니다. 그래서 git hook을 공유하기 위한 여러가지 방법들이 나왔는데 저는 그 중 husky를 사용해보고자 했습니다.

Husky 도입 🐶

Husky

• git hook에 따라 원하는 동작을 하게 도와주는 패키지
• git hook에 대한 정책을 관리하고 공유할 수 있다.
• git add나 commit, push가 시행되기 전이나 후 등 여러 조건에 원하는 스크립트를 실행시켜준다.

husky 설치

yarn add --dev husky

package.json에 코드 작성

"scripts": {
    "prepare": "husky install"
}

husky 폴더 생성

명령어를 실행하고 나면 .husky 폴더가 생성됩니다.

yarn prepare

해당 폴더에서 스크립트 파일을 추가할 수 있습니다.

특정 이벤트에 실행할 스크립트 추가 (pre-commit)

해당 스크립트를 추가하면 .husky 폴더 안에 pre-commit 파일이 생성됩니다. husky에서 제공하는 다양한 시점이 있지만, 대부분 pre-commit을 사용하는 것 같았습니다. lint 검사 뿐만 아니라 테스트를 진행할 수도 있으니 다양한 부분에서 활용이 가능합니다.

npx husky add .husky/pre-commit 'yarn init'

추후에 'yarn init'과 같은 명령어가 수정되면 해당 파일 안에서 수정하면 됩니다. commit 전에 'yarn init' 명령어를 실행하는 코드입니다.

lint-staged ⚙️

lint-staged는 git에서 stage 단계에 있는 파일들만 검사해주는 라이브러리입니다.

위와 같이 작업을 하다보니 제가 작업한 파일만 lint 검사를 하는 것이 아니라, 모든 프로젝트 파일에 대해서 lint 검사를 진행하게 됐습니다. 제가 작업한 파일에 대해서만 검사를 해줄 수 있는 도구가 필요했습니다.

lint-staged 설치

yarn add --dev lint-staged

package.json에 코드 작성

"scripts": {
    "lint-staged": "lint-staged"
}
"lint-staged": {
    "src/**": [
        "eslint"
    ]
}

pre-commit 파일 수정

yarn init --> yarn lint-staged

마무리

위의 내용들은 eslint가 설정이 되어 있는 가정이 있습니다.

husky와 lint-staged를 적용했기 때문에, 앞으로는 디버그할 때는 자유롭게 코드를 작성해서 사용할 수 있습니다! 👏 협업하기 위해서 git을 사용하는 순간에는 lint 검사를 진행하게 될 것입니다.

prettier write 같은 작업도 같이 할 수 있고 테스트 코드에 대한 테스트도 진행할 수 있습니다. 코드 퀄리티도 더 보장이 잘 될 것이고, 코딩 컨벤션도 잘 지킬 수 있게 되겠죠! 개인적으로 Husky와 lint-staged의 적용은 너무 만족하고 있습니다!

아직 해결하지 못한.. 🤦‍♂️

eslint 검사를 진행할 때 warning만 나온다면, warning에 대한 표시는 해주지 않고 통과됩니다.. warning을 띄워주고 commit이 되야할 것 같은데 말이죠..

그래서 error가 있을 때만 같이 보여주고 이후의 작업이 멈춥니다. 이 부분은 조금 더 확인을 해봐야될 것 같습니다!

혹시나 sourceTree를 사용한다면 🌲

yarn을 찾을 수 없다는 메시지가 계속 나와서 한참을 헤맸습니다.. 맥에서 node와 관련된 경로 이슈로 나와 있는데.. 저는 다른 방향으로 해결이 됐습니다!

기존에 pre-commit에 작성된 yarn을 npx로 변경했더니 문제가 해결됐습니다.. ㅎ 이후에는 sourceTree와 Intellij와 같은 IDE에서도 제대로 동작이 됐습니다.

기본적으로 IDE 터미널에서 해당 내용을 파악하는 것이 개인적으로 제일 편했습니다. 해당 소스코드를 바로 찾아갈 수 있다는 장점이 제일 큰 것 같습니다!

출처

• https://ms3864.tistory.com/412

읽고, 관리하기 쉬운 코드를 작성하기 위한 일종의 코딩 스타일 규약 린터를 사용한다는 가정하에 린터로 검출할 수 없는 모호한 부분을 가이드

이번에 회사에서 마크업 코딩 컨벤션 관련해서 정리하게 될 기회가 생겼습니다. 여러 포스팅들을 찾아보고 저희한테 맞는 코딩 컨벤션을 작성하기 위해서 자료를 정리해봤는데요. 회사에서는 웹앱으로 서비스가 제공되고 있어서 보편적인 웹서비스에 적용할 수 있는 마크업 코딩 컨벤션보다는 내용이 적습니다.

추가적으로 CSS에 대한 코딩 컨벤션은 작성하지 않았고, Naming Rule 에는 파스칼 케이스, 카멜 케이스, 케밥 케이스, 스네이크 케이스 등 다양한 케이스에 대한 내용을 작성하지는 않았습니다. 스네이크 케이스로 작성하기로 결정된 상태여서 스네이크 케이스를 기준으로 작성합니다.

🧑‍💻 마크업 컨벤션의 필요성

마크업 개발은 디자인, 브라우저, 스크립트, 성능, 접근성 등과 긴밀한 관계가 있습니다. 또한, 유지보수에 투자되는 비용을 최소화하기 위해 통일된 코드 작성법을 제시합니다.

개발을 하면서 코드를 최초로 작성한 사람이 끝까지 유지보수할 확률은 매우 낮습니다. 따라서, 최초 개발자가 아닌 사람도 코드를 빠르고 정확하게 이해할 수 있도록 작성하는 것은 코드의 유지보수 비용을 절감하고 업무 효율을 높이는데 결정적인 역할을 합니다.

어떤 코딩 컨벤션을 선택하는 것이 중요한 것이 아니라, 통일된 기준으로 소스 코드를 작성하는 것이 중요합니다.

📚 용어 정리

컨벤션에 자주 사용되는 용어의 정의를 설명합니다.

엘리먼트 (Element)

HTML 문서를 구성하는 요소(태그)를 의미합니다.

애트리뷰트 (Attribute)

엘리먼트에 부여할 수 있는 특성을 의미합니다.

선택자 (Selector)

엘리먼트를 식별할 수 있는 이름을 의미합니다.

요소에 CSS 스타일을 적용하기 위한 패턴입니다.

컴포넌트 (Component)

하나 이상의 기능 또는 역할을 가진 컨텐츠 단위의 UI 구성 요소를 의미합니다.

Syntax

• 들여쓰기는 2개의 공백 문자(소프트탭)을 사용합니다.
• 모든 엘리먼트 명과 애트리뷰트 명은 스네이크 표기법(Snake Case)로 작성합니다.
• 모든 애트리뷰트 값은 큰 따옴표("")를 사용합니다.
• 닫는 태그가 선택적이어도 생략하지 않습니다. (ex: </li>, </body>)
• 빈 줄은 1줄을 초과하지 않습니다.
• EditorConfig 사용을 권장합니다.

EditorConfig 환경(Editor, OS, file encoding)에 따라 코딩 스타일의 일관성이 깨지는 문제를 해결하기 위한 표준 character encoding, 개행 처리 방법, 들여쓰기 방법(tab or space) 등을 정의

Doctype

HTML5 DTD(Document Type Definition)로 선언합니다. 추가적으로 자기 마침 태그 (Self-Closing Tags)에 후행 슬래시(/)를 사용하지 않습니다.

<!-- Bad -->
<input />
<br />

<!-- Good -->
<input>
<br>

Naming Rule

• 이름은 영문 소문자, 숫자, 언더스코어(_)로 작성합니다.
• 시작 이름은 영문 소문자로만 시작할 수 있습니다.
• 언더스코어는 단어와 단어를 조합할 때만 사용합니다.
• 언더스코어가 포함된 약속어는 숫자, 영문 소문자와 조합하여 사용할 수 있습니다.

id, class Naming Rule

• id는 문서 전체의 고유 식별자 이므로 한 문서에서 동일한 id를 여러 번 사용하지 않습니다.
• 레이아웃을 제외한 id는 스타일을 지정하지 않습니다.
• class는 문서에서 여러 번 사용할 수 있습니다.

HTML 코드 작성 규칙

W3C Validation

• HTML은 DTD의 명세에 맞게 작성하며, W3C Validation을 통과해야 합니다.
• DTD를 제외한 모든 엘리먼트와 애트리뷰트는 소문자로 작성합니다.

<!-- Bad -->
<SPAN Class="desc">간단한 설명</SPAN>

<!-- Good -->
<span class="desc">간단한 설명</span>

HTML 애트리뷰트 작성 규칙

기본 규칙

• 엘리먼트에서 class, style을 선언할 때는 선언 순서를 준수합니다.
• class, style을 선언할 때는 제일 뒷부분에 선언합니다.
• 애트리뷰트의 순서가 비슷한 엘리먼트끼리 통일되므로 검색하기 편해집니다.

<!-- Good -->
<input type="text" id="user_id" title="사용자" class="input_txt" style="width:100px">

선언 순서

type = src > id = title = name > class > style

Boolean 애트리뷰트

• HTML5에서는 Boolean 애트리뷰트를 선언하는 것만으로도 true 값을 가집니다.
• 필요하지 않다면 Boolean 값을 작성하지 않습니다.

<!-- Not Bad -->
<button disabled="true"></button>

<!-- Good -->
<button disabled></button>

name 애트리뷰트

• name 애트리뷰트 값은 비즈니스 로직을 작성하는 언어의 Naming Rule에 맞게 작성하는 것을 권장합니다.
• 저희는 Snake Case를 사용하고 있기 때문에 동일한 Naming Rule을 사용하면 됩니다.

<!-- Snake Case -->
<form class="form" id="my_form" name="my_form">
    <input class="input" type="text" id="my_user_name" name="my_user_name">
</form>

HTML 엘리먼트 작성 규칙

<input>

• label 요소, title 애트리뷰트, alt 애트리뷰트를 통해 스크린 리더 사용자는 주변 맥락에 대한 이해 없이 각 요소에 독립적으로 접근해도 폼을 이해할 수 있습니다.

type이 text인 경우

• 동일한 스타일의 텍스트 필드나 너비 값이 다를 경우 style 애트리뷰트를 이용해서 width 값을 제어합니다.
• 이렇게 하면 불필요한 클래스 생성을 막을 수 있습니다.

<!-- Bad -->
<input type="text" class="input input--width-120">
<input type="text" class="input input--width-180">

<!-- Good -->
<input type="text" class="input" style="width:120px">
<input type="text" class="input" style="width:180px">

type이 radio, checkbox인 경우

• 그룹핑이 필요하면 선택적으로 name 애트리뷰트를 이용하여 항목들을 그룹핑합니다.

type이 image인 경우

• alt 애트리뷰트를 반드시 선언합니다.

<label>

• <input>, <select>, <textarea>와 같은 폼 요소는 for 애트리뷰트를 부여하여 해당 요소의 id 값과 동일한 이름으로 연결(coupling)합니다.
• 단 레이블 명이 위치할 공간이 없는 경우 title 애트리뷰트로 대체할 수 있습니다.
• <label> 안에 <input> 엘리먼트가 있는 경우에는 for와 id를 이용하여 연결하지 않아도 됩니다.

<!-- for, id를 이용한 커플링 -->
<input type="radio" name="alignment" id="align_left">
<label for="align_left">왼쪽 정렬</label>

<!-- <label>안에 <input> 엘리먼트가 있는 경우 -->
<label><input type="checkbox" name="sports">축구</label>

<img>

• src, width, height, title, alt, usemap 애트리뷰트를 선택적으로 선언합니다.
• src, alt 애트리뷰트에 import한 이름과 동일한 값을 표기합니다.
• 이미지를 볼 수 없는 환경(스크린 리더, 이미지 서버 장애, 이미지를 표시하지 않음 설정)에서도 내용을 확인할 수 있게 합니다.
• title 애트리뷰트를 선언한 경우에도 alt 애트리뷰트를 함께 선언합니다.
• title 애트리뷰트는 브라우저에서 독립적으로 툴팁을 표현하기 위해서 사용합니다.

<!-- import, src, alt 애트리뷰트 -->
import FinanceBanner from '../../banner01.jpg'

<img src={FinanceBanner} alt="FinanceBanner">

<!-- 애트리뷰트 사용 예시 -->
<img src={FinanceBanner} width="30" height="10" title="배너" alt="배너" usemap="#help">

NHN 코딩 컨벤션이나 다른 코딩 컨벤션을 확인해보면 더욱 자세한 컨벤션 내용을 확인할 수 있습니다. 🔎

누군가 이 내용을 봤을 때 컨벤션으로 많이 부족하다고 생각할 수 있습니다. 해당 내용을 다 적용하면 좋지만, 어떤 코딩 컨벤션을 선택하는 것이 중요한 게 아니라 우리에게 필요한 통일된 기준이 필요했습니다. 그러한 기준으로 봤을 때 현재 작성된 내용은 개인적으로 만족스럽습니다

혹시나 코딩 컨벤션을 정해야 하는 상황이라면 현재 가지고 있는 익숙함에 필요한 컨벤션을 추가하면서 코딩 컨벤션을 만들어가면 좋을 것 같습니다. 💪

출처

• NHN 코딩 컨벤션
• https://github.com/choegyumin/markup-coding-conventions

일상 속에서 릴리즈 노트와 가장 비슷한 노트를 찾을 수 있는 가장 쉬운 방법은 무엇일까요?

제가 생각한 방법은 바로 게임 업데이트(패치) 노트를 확인하는 것입니다. 어떠한 새로운 이벤트들이 추가 됐는지, 캐릭터의 밸런스 패치, 버그 수정 등 쉽게 보면 게임 업데이트 노트에서 가장 쉽게 볼 수 있는 것 같습니다.

릴리즈 노트 === 게임 패치 노트

릴리즈 노트와 게임 패치 노트가 같은 개념인지(?)는 정확하게 모르겠지만..! 위와 같이 생각하고 접근해봅시다!

릴리즈 노트란? 📖

• 소프트웨어 또는 서비스가 출시 또는 업데이트 될 때마다 해당 상품의 배포와 함께 변경 사항, 기능 추가/삭제, 버그 개선 등 변경 사항을 체계적으로 정리하여 정보를 제공하는 문서
• 릴리즈 노트는 정보 공유 뿐만 아니라 회사에 대한 긍정적인 인상을 심어주는 중요한 역할을 한다.

게임으로 대입해보면 새로운 캐릭터의 출시, 직업 버그 수정, 기존 사냥터 리뉴얼 등 여러가지 서비스의 변경 사항을 정리해서 보여줍니다.

이러한 릴리즈 노트를 보면 회사가 서비스를 개선하기 위해 열심히 노력하고 있다고 생각할 수 있습니다.

릴리즈 노트가 꼭 작성되어야 하는 이유 📚

1. 업데이트 정보를 한 곳에 모아 기록함으로써, 내가 작업하지 않은 업데이트 사항도 빠르게 파악 가능
2. 릴리즈 노트를 보면 누구나 제품의 발자취를 한 눈에 파악 가능
3. 우리 회사의 제품 혹은 서비스가 지속적으로 개선되고 최신의 상태를 유지하고 있음을 안내
4. 사용자의 신고와 의견을 반영하고 있다는 인상을 주어 사용자의 적극적인 피드백을 유도

구글 클라우드 서비스 팀의 릴리즈 노트를 보면 날짜를 기준으로 정리된 릴리즈 노트를 확인할 수 있습니다.

릴리즈 노트와 게임 패치 노트를 비교해보면 3, 4번은 오히려 게임 패치 노트에서 더 중요하다고 생각할 정도인데요.

1, 2번은 게임 패치 노트에서 한 눈에 파악하기는 조금 어려운 것 같습니다.

아무래도 패치 노트는 이미지의 추가, 긴 설명 등의 차이가 있기 때문이죠.

릴리즈 노트의 구성 요소 ⚙️

릴리즈 노트의 구성요소는 따로 정해져 있지는 않습니다.

회사나 조직마다 준수해야 하는 릴리즈 노트 표준은 존재하지 않는다.

그래서 제가 참고한 구글 클라우드, 카카오 테크, NHN 클라우드 등 여러 서비스의 릴리즈 노트 양식은 다 다릅니다. 하지만 일반적으로 릴리즈 노트는 버전, 날짜, 구분, 설명으로 구성됩니다.

버전

버전을 작성하지 않는 서비스들도 있습니다. 하지만 개인적으로 버전을 작성하는 것이 릴리즈 노트를 훨씬 효과적으로 확인할 수 있는 방법이라고 생각합니다.

독자들은 릴리즈 노트만 보고 신규 업데이트나 버그 픽스 등의 소프트웨어의 변경 범위를 대략적으로 유추할 수 있습니다.

날짜

영어식 표기 또는 국어식 표기 중 하나의 스타일을 정하고 전체 문서에서 일관된 스타일을 유지하는 것이 중요합니다. 구글을 포함한 여러 글로벌 IT 회사들은 스타일 가이드에 날짜 표기 방식에 대한 구체적인 정의를 포함하고 있습니다.

구분

해당 기능이 신규 추가 항목인지, 또는 수정 항목인지 변경 사항을 빠르게 파악할 수 있도록 도와줍니다.

태그(tag)의 역할을 하고 있습니다. 일반적으로는 New(최초), Feature(기능), Changed(변경), Fixed(수정), Deprecated(중단) 등의 항목이 포함될 수 있습니다.

해당 구분에 대한 내용도 본인이 속한 조직에서 자유롭게 정할 수 있습니다.

너무 다양하다면 해당 구분 태그를 관리하기 어렵고,너무 적으면 구분 태그로 표현하기가 어려울 것입니다.

설명

상품이나 서비스의 특성에 따라 릴리즈 노트의 설명 부분이 한 줄로 간략하게 끝날수도 있고, 자세하게 풀어쓰는 것도 가능합니다.

하지만 일반적으로 릴리즈 노트는 간략하고 집약적으로 작성하는 것이 일반적입니다. 그래서 자세하게 내용을 풀어서 쓰고 싶다면 관련 문서 링크를 연결하는 것도 좋습니다.

릴리즈 노트 작성 Tip 🙌

"버그 수정 및 성능 개선"은 지양

위의 문구를 반복적으로 사용하는 것은 지양해야 합니다.

적어도 어떤 버그가 개선되었는지, 어떤 기능이 어떻게 변경되거나 추가 되었는지 사용자가 파악할 수 있도록 작성하는 것이 좋습니다. 릴리즈 노트를 즐겨 읽고 개선된 기능을 빨리 사용해보고 싶어하는 독자들에게 알맞은 정보를 전달해주어야 합니다.

짧게 작성하고, 링크를 활용

제가 찾아봤을 때 이 부분은 상반된 의견을 보였는데요. 처음부터 간결하게 쓰려고 노력하면 꼭 들어가야 할 정보가 빠져 있거나, 모호한 노트를 쓰게 된다고 의견을 내는 사람이 있습니다.

반대로 가독성이 떨어지지 않게 최대한 간결하게 적는 것이 중요하다. 너무 길어지만 매뉴얼 본문을 보는 듯한 착각에 빠질 수 있다는 의견을 내는 사람도 있습니다. 그리고 자세한 안내를 원한다면 문서 페이지의 링크를 안내하는 것이 좋다고 말합니다.

사실 두 의견의 결과는 모두 짧게 작성하는 것입니다. 하지만 과정의 차이가 있을 뿐이죠. 본인이 훈련하고 싶은 방법으로 작성해보는 것이 어떨까요?

일관된 용어를 사용하라

릴리즈 노트를 작성하는 작성자마자 사용하는 용어가 다른 경우가 존재합니다.

BOT Response 기능 추가, Bot 응답 개선, 봇의 응답 방식 개선 등 같은 의미를 가지고 있지만 작성자가 사용하는 용어마다 전혀 다른식으로 표현이 됩니다.

이러한 경우 동일한 의미를 가진 여러 단어를 일관된 용어를 사용할 필요가 있습니다.

매우 사소해 보이지만, 매우 중요한 포인트라고 생각이 듭니다. 조직 내에서 작성자의 역할이 분명하거나, 모든 개발자가 작성에 참여할 경우에는 원활한 소통이 필요할 것입니다.

사용자 관점에서 쉽게 작성하라

릴리즈 노트는 독자를 위한 문서입니다. 그렇기 때문에 사용자가 주어라고 생각하고 글을 작성하는 것이 가독성을 높일 수 있습니다.

시각적 효과(그룹화)를 적용하라

사용자는 자신이 제보한 버그가 수정되었는지, 이번 버전에는 신규 기능이 있는지 등의 특정 목적을 가지고 릴리즈 노트를 읽습니다. 같은 내용이라도 색을 활용하여 구분을 나타내고 여백 또는 구분선 등을 활용하여 섹션을 구분하는 등 시각적 효과를 적용하면 릴리즈 노트의 가독성을 개선할 수 있습니다.

릴리즈 노트 작성하기

제가 사내 릴리즈 노트를 작성하면서 많이 참고했던 kakaoi의 릴리즈 노트입니다. Bot 시작 가이드라는 서비스에 대한 릴리즈 노트를 가져 왔는데요. 해당 릴리즈 노트의 버전을 쭉 확인할 수 있습니다.

혹은 날짜를 기준으로 하위에 서비스명을 두고 릴리즈 노트를 작성해도 됩니다. 해당 릴리즈 노트는 google cloude service 릴리즈 노트입니다. 버전을 따로 존재하지 않고, 날짜를 기준으로 릴리즈 노트를 작성하고 있습니다.

두 릴리즈 노트 모두 설명은 길지 않게, 추가적인 설명은 텍스트에 링크를 붙여놓은 것을 볼 수 있습니다.

마무리

사내에서 사용할 릴리즈 노트를 작성하기 위해서 처음 릴리즈 노트를 찾아보고 정리해봤는데요. 릴리즈 노트의 경우에는 기존의 IT 기업들의 사례를 잘 조합해서 사용하는 것이 좋다고 생각합니다. 그래서 아예 처음부터 새로운 양식으로 만들어봐야겠다는 생각은 하지 않았던 것 같습니다.

출처에 첨부된 카카오 테크의 릴리즈 노트 작성법을 보시면 제가 정리한 내용보다 더 자세한 내용을 확인하실 수 있습니다.

출처

• https://tech.kakaoenterprise.com/113

• https://engineering.linecorp.com/ko/blog/write-the-docs-prague-2018-recap/

• https://cloud.google.com/release-notes

• https://docs.kakaoi.ai/kakao_work/release_note/

다른 자료들을 찾아보시면 훨씬 더 많은 컨벤션 내용을 확인하실 수 있습니다. 저는 TypeScript 컨벤션으로 분류될 수 있을만한 내용만 간단하게 추려보았습니다. 대부분의 내용은 JavaScript 코딩 컨벤션과 관련된 내용이 많았습니다. 📚

인터페이스 (Interface)

PascalCase를 사용합니다. I를 접두어로 사용하지 않습니다.

• 이전에는 인터페이스 변수 앞에 I를 붙이는 경우가 많았는데 현재는 비관습적인 이유로 사용하지 않습니다.

// Bad
interface IFoo {
}

// Good
interface Foo {
}

타입 (Type)

PascalCase를 사용합니다. 멤버는 camelCase를 사용합니다.

// Bad
type car {
    ModelInfo: string;
}

// Good
type Car {
    modelInfo: string;
}

Type vs Interface

Union이나 Intersection이 필요할 때 Type을 사용합니다.

type Foo = number | { someProperty: number }

extends 또는 implements를 사용하고 싶을 때는 Interface를 사용합니다.

interface Foo {
    foo: string;
}

interface FooBar extends Foo {
  bar: string;
}

class X implements FooBar {
    foo: string;
    bar: string;
}

네임스페이스 (namespace)

PascalCase를 사용합니다.

• 타입스크립트 팀에서 정한 약속입니다.
• 네임스페이스들은 정적멤버를 갖는 클래스, 클래스 이름도 PascalCase를 사용하기 때문에 동일하게 사용합니다.

  // Bad
  namespace foo {
  }
  

// Good namespace Foo { }

## `enum`

`PascalCase`를 사용합니다.
`enum`의 멤버에는 `PascalCase`를 사용합니다.
- 타입스크립트 팀에서 정한 약속입니다.
```typescript
// Bad
enum color {
    red
}

// Good
enum Color {
    Red
}

any vs unknown

• unknown 타입을 사용합니다.
• any, unknown 타입 모두 아무때나 사용할 수 있지만 unknown 타입은 사용하는 쪽에서 방어처리를 해서 안전하게 사용이 가능합니다.
• any 타입은 타입스크립트를 쓰는 의미가 없게 되버릴 수 있습니다.

function prettyPrint(x: unknown): string {
  if (Array.isArray(x)) {
    return "[" + x.map(prettyPrint).join(", ") + "]"
  }
  if (typeof x === "string") {
    return `"${x}"`
  }
  if (typeof x === "number") {
    return String(x)
  } 
  return "etc."
}

x를 any로 했을 경우 map(), join()을 사용할 수 있는데 unknown일 때 x가 배열인 경우에만 map(), join()을 사용할 수 있도록 강제해줍니다.

null vs undefined

• 명백히 값이 없을 때에도 사용하지 않도록 합니다.
• 타입스크립트에서 type으로 구조를 암시할 수 있도록 합니다.

  // Bad
  let foo = { x: 123, y: undefined }
  

// Good let foo = { x: number, y?: number } = { x: 123 }

일반적으로 `undefined`를 사용합니다.

```typescript
return undefined

null이나 undefined 값을 갖는 객체는 truthy하게 검사합니다.

// Bad
if (error === null)

// Good
if (error)

null이나 undefined를 체크할 때 === 혹은 !==를 사용하지 않고 == 혹은 !=를 사용합니다.

• null이나 undefined에는 작동하지만 다른 fasly 값들 ('', 0, false)에는 작동하지 않습니다.

  // Bad
  if (error !== null)
  

// Good if (error != null)

```

출처

• https://radlohead.gitbook.io/typescript-deep-dive/styleguide
• https://techblog.woowahan.com/9804/
• https://738.github.io/clean-code-typescript/
• https://github.com/tipjs/javascript-style-guide
• https://velog.io/@cada/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-%EC%BD%94%EB%94%A9-%EB%B0%8F-%EB%84%A4%EC%9D%B4%EB%B0%8D-%EC%BB%A8%EB%B2%A4%EC%85%98-1%ED%8E%B8

styled-components와 달리 emotion에서는 stylelint를 설정하는 방법이 따로 없었습니다. 공식문서를 봐도 stylelint와 관련된 내용을 찾아보기 어려웠습니다. 🤦‍♂️

몇 일동안 정말 다양한 문서를 봤던 것 같습니다... 모든 포스팅이 그렇듯 시간이 지남에 따라 버전에 대한 문제도 있었고, 더 이상 지원하지 않는 플러그인을 가지고 적용하는 방법 등 제대로 적용할 수 있는 방법을 찾지 못했습니다.

그래서 styled-components로 옮겨가야 되겠다라고 생각하고 있었죠.. 🚚

저는 emotion에서도 주로 styled 키워드를 자주 사용하는데요. 그래서 styled-components의 stylelint 설정 방식을 emotion에 그대로 적용해보았습니다! 다행히..! emotion의 styled 키워드에서는 잘 작동을 했습니다!! 🙌

저와 같이 emotion과 stylelint, css 속성 정렬을 같이 해보고 싶으신 분들은 아래의 포스팅을 봐주시면 됩니다!

Emotion 설치

React

$ yarn add @emotion/react @emotion/styled

React Native

$ yarn add @emotion/react @emotion/native

StyleLint 설치

$ yarn add --dev stylelint stylelint-config-standard stylelint-order postcss-styled-syntax

• stylelint : stylelint를 사용하기 위한 기본적인 패키지
• stylelint-config-standard : stylelint에서 표준으로 제공하는 규칙에 대한 패키지
• stylelint-order : CSS 속성에 대한 그룹 및 순서를 작성할 수 있는 패키지
• postcss-styled-syntax : styled로 작성된 CSS 속성들을 파싱해주는 패키지

stylelint 15버전 이상을 기준으로 작성했습니다.

styled-components의 stylelint 설정 방식을 그대로 가져와서 emotion에 적용했습니다. 그래서 emotion에서 사용하는 The css Props와 같은 형식에는 적용이 되지 않을수도 있습니다.

.stylelintrc.json 파일 작성

{  
  "extends": ["stylelint-config-standard"],  
  "plugins": ["stylelint-order"],  
  "customSyntax": "postcss-styled-syntax",  
  "rules": {  
      // css 속성 작성 시 empty line 관련 설정
    "declaration-empty-line-before": [  
      "always",  
      {  
        "ignore": [  
          "first-nested",  
          "after-comment",  
          "after-declaration",  
          "inside-single-line-block"  
        ]  
      }  
    ],  
    "order/order": ["custom-properties", "declarations"],  

    // css 속성 그룹 및 순서 설정
    "order/properties-order": [  
      {  
          // 그룹 이름 설정
        "groupName": "Layout",  
        // 그룹 내부 emptyline 사용 여부
        "noEmptyLineBetween": true,  
        // 그룹 css 속성 멤버
        "properties": [  
          "display",  
          "visibility",  
          "overflow",  
          "float",  
          "clear",  
          "position",  
          "top",  
          "right",  
          "bottom",  
          "left",  
          "z-index"  
        ]  
      },  
      {  
        "groupName": "Box",  
        "emptyLineBefore": "always",  
        "noEmptyLineBetween": true,  
        "properties": [  
          "width",  
          "height",  
          "margin",  
          "margin-top",  
          "margin-right",  
          "margin-bottom",  
          "margin-left",  
          "padding",  
          "padding-top",  
          "padding-right",  
          "padding-bottom",  
          "padding-left",  
          "border"  
        ]  
      },  
      {  
        "groupName": "Background",  
        "emptyLineBefore": "always",  
        "noEmptyLineBetween": true,  
        "properties": ["background-color"]  
      },  
      {  
        "groupName": "Font",  
        "emptyLineBefore": "always",  
        "noEmptyLineBetween": true,  
        "properties": [  
          "color",  
          "font-style",  
          "font-weight",  
          "font-size",  
          "line-height",  
          "letter-spacing",  
          "text-align",  
          "text-indent",  
          "vertical-align",  
          "white-space"  
        ]  
      },  
      {  
        "groupName": "Animation",  
        "emptyLineBefore": "always",  
        "noEmptyLineBetween": true,  
        "properties": ["animation"]  
      }  
    ]  
  }  
}

stylelint-order 플러그인에 대한 내용을 github을 통해서 추가적으로 찾아보시는 것을 추천드립니다.

페이지에 룰에 대한 자세한 설명들이 포함되어 있습니다.

StyleLint script 작성

// package.json
{
    "scripts": {
        "lint:styled": "stylelint './src/**/*.styles.ts' --fix",
    }
}

Lint 검사

npm run lint:styled

앞으로 Lint 검사를 Husky와 같이 git hook과 연계해서 사용하거나 vscode의 경우에는 stylelint 플러그인을 잘 지원해주는 것으로 알고 있습니다. Intelij의 경우에는 File Watcher 플러그인을 별도로 설치해서 사용해야 합니다.

적용 예시

// components/CustomText/CustomText.styles.ts
import styled from '@emotion/native';  

export const CustomText = styled.Text`  
  display: flex;
  width: 200px;
  margin: 10px;
  padding: 10px;
  border-radius: 100%;

  background-color: black;  

  color: #e9ecef;
  font-weight: bold;
  font-size: 14px;  

  animation: ease;`;

현재 느낀 단점은 .stylelintrc.json 파일 내부에 작성하지 않은 css의 속성의 경우에는 어떠한 룰도 적용되지 않는 점입니다.

플러그인에서 어느정도 그룹핑을 제공하면 좋을 것 같습니다.

stylelint-semantic-groups, stylelint-config-rational-order, stylelint-config-idiomatic-order 등의 플러그인을 사용하면 기본적으로 제공하는 그룹핑이 있는 것 같습니다.

정리

emotion + stylelint를 적용하기 위해서 정말 많은 자료를 찾아보고 시간을 사용했던 것 같습니다.. 🤯

아직 stylelint-config-standard에 대한 자세한 룰을 적용하지 않았고, 정렬에 대한 자세한 룰도 적용하지 않았습니다. 본인이 사용하시고 싶은 CSS 컨벤션이 있다면, 이번 기회를 통해서 시스템화 하는 것도 좋은 기회라고 생각합니다!

출처

• https://emotion.sh/docs/@emotion/native
• https://styled-components.com/docs/tooling#stylelint
• https://github.com/hudochenkov/stylelint-order
• https://github.com/theKashey/stylelint-semantic-groups
• https://github.com/constverum/stylelint-config-rational-order

업무, 개인 프로젝트 등 우리는 커밋 메시지를 매일 작성합니다.

개인적으로 그만큼 제대로 신경쓰지 않고, 커밋 메시지를 작성했던 것 같습니다. 오늘은 이렇게 신경쓰지 않은 커밋 메시지 작성법에 대해서 나눠보려고 합니다. 사실 회사에서는 이렇게 커밋 메시지를 작성하세요! 라고 하는 내용은 없습니다.

기본적으로 많이 사용하는 [FEAT], [FIX], [REMOVE]와 같은 타입과 제목 정도는 작성하고 있었습니다.

하지만 점점 작성하다보니, 내가 커밋 메시지를 잘 쓰고 있는건가? 🤔 라는 의문이 들기 시작했습니다. 과거의 커밋 이력을 보고 있는데, 제가 작성한 커밋 메시지를 이해 못하고 있었습니다... 🤯 이 순간은 매우매우 충격적이었습니다..

사실 평소에도 나는 커밋 메시지를 자세하게 잘 쓰고 있어! 라는 생각을 하지는 않았습니다. 하지만 실제로 커밋 메시지를 보니 왜 이런 기능을 작성했는지, 자세한 내용은 하나도 이해가 되지 않았습니다.. 대충 어떤 내용의 작업이라는 것만 적혀있고, 왜 이러한 코드를 썼는지, 자세한 내용들이 안 남아 있었습니다.

부족함을 알았으니, 미래의 나를 조금이라도 덜 힘들게 하기 위해서, 커밋 메시지 작성법에 대해서 정리를 해보려고 합니다.

구조

제목, 본문, 꼬리말, 세가지 파트로 구분합니다.

각 파트는 빈 줄을 두고 구분합니다.

다른 포스팅을 많이 참고하려고 했는데, 대부분 동일한 컨벤션을 가지고 있었습니다.

type: 제목

본문

꼬리말

제목

type: 제목

type:

• feat : 새로운 기능 추가
• fix : 버그 수정
• docs : 문서 업데이트
• style : style과 관련 코드 수정
• refactor : 코드 리팩토링
• test : 테스트 코드 작성, 수정
• chore : 패키지 설치 및 환경 설정
• rename : 파일 혹은 폴더명 수정 혹은 이동
• remove : 파일 삭제

제목

• 간략하게 변경 이유와 이 커밋으로 어떤 점이 달라지는지 명시합니다.
• 과거형 대신 현재형으로 작성합니다.
• 끝에 점(.)을 붙이지 않습니다.

feat: 네이버 소셜 로그인 기능을 구현 함. (X)

feat: 네이버 소셜 로그인 기능 구현 (O)

다른 포스팅을 많이 참고하려고 했는데, 대부분 비슷한 컨벤션을 가져가고 있었습니다. 그리고 type:을 7가지로 작성하신 분들이 많았습니다.

개인적으로 굳이 7개로 한정해서 나눌 필요는 없다고 생각이 듭니다. type은 자유롭게 넣고 빼고 해도 괜찮다고 생각합니다. (사실 feat, fix를 제일 많이 사용하겠지요..!)

대문자로 시작하지 않는다는 규칙도 있었는데요. 이 부분은 영어로 커밋 메시지를 작성할 때 대문자로 시작하지 말라는 이야기였습니다. 개인적으로 아직은 영어로 커밋 메시지를 작성할 용기가 나지 않기 때문에.. 패스하도록 하겠습니다 🏃

본문

• 긴 설명이 필요한 경우에 작성합니다.
• 어떻게 보다는 무엇을, 왜 변경했는지에 대해서 작성합니다.
• 본문의 양에 구애 받지 않고, 최대한 상세하게 작성합니다.
• 이 변경을 통해서 side effect나 고려해야 될 사항이 있다면 작성합니다.

예시를 한 번 작성해보려고 했는데요.

무엇을, 왜 변경했는지에 대한 내용을 작성하는게 꽤나 힘든 것 같습니다. 🤔

꼬리말

• 꼬리말은 optional입니다.
• 유형: #이슈 ID 형식으로 작성합니다.

Fixes: #45
Related to: #34, #23

마무리

대부분의 개발자들은 커밋의 순서를 따라가면서 다른 동료분들이 작성한 코드를 파악합니다. 그리고 코드에 대한 의견이 있다면, 리뷰를 남기면서 코드리뷰를 진행하기도 합니다.

저 또한 코드리뷰를 진행할 때 그런식으로 진행하는데요. 이 때 커밋 메시지를 잘 작성해두면 코드 리뷰 혹은 저처럼 과거의 내용을 파악할 때 조금 더 효과적으로 내용을 확인할 수 있을거라고 기대합니다.

출처

• https://devinn.dev/blog/detail.html?id=115
• https://velog.io/@shin6403/Git-git-%EC%BB%A4%EB%B0%8B-%EC%BB%A8%EB%B2%A4%EC%85%98-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0
• https://overcome-the-limits.tistory.com/entry/%ED%98%91%EC%97%85-%ED%98%91%EC%97%85%EC%9D%84-%EC%9C%84%ED%95%9C-%EA%B8%B0%EB%B3%B8%EC%A0%81%EC%9D%B8-git-%EC%BB%A4%EB%B0%8B%EC%BB%A8%EB%B2%A4%EC%85%98-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0

본 뜻을 찾아보면, '톺다'라는 뜻은 틈이 있는 곳마다 모조리 더듬어 뒤지면서 찾다 라는 뜻입니다. '톺아보기'는 샅샅이 톺아 나가면서 살피다 라는 뜻을 가지고 있습니다.

Git이란 무엇인가? 🤔

• 리누스 토발즈가 리눅스 커널 개발에 사용할 관리 도구 용도로 개발
• 분산 버전 관리 시스템으로 지역 저장소와 원격 저장소가 존재
• 여러 사람이 같은 코드를 수정하고 공유하며, 하나의 파일로 모든 버전을 관리할 수 있다. 또한 동시에 같은 부분을 수정했을 때 생기는 문제들을 해결할 수 있다.

git을 사용하는 가장 큰 이유는 버전관리와 협업입니다.

꼭 git을 써야만 버전관리를 할 수 있는 것은 아닙니다. 하지만 많은 개발자들이 보편적으로 git을 사용하고 있고, 다른 개발자와 협업을 하기 위해서는 많이 사용하는 것을 먼저 배우는 것이 좋겠죠?

git은 지역 저장소에서 버전 관리가 수행됩니다. 그렇기 때문에 원격 저장소나 네트워크에 문제가 있어도 작업이 가능합니다. 원격 저장소는 여러 사람들이 협업을 위해 버전이 공동으로 관리되는 곳입니다. 자신의 버전 내역을 반영하거나, 다른 개발자의 반영된 버전 내역을 가져올 때 사용합니다.

그렇다면 github는 무엇일까요?

Github는 무엇인가? 🤔

• git 저장소 호스팅을 지원하는 웹 서비스

git을 사용하는 프로젝트를 지원하는 웹 호스팅 서비스이기 때문에, git을 사용하는 프로젝트를 모두 github에서 관리할 수 있습니다. gitlab처럼 다른 호스팅 서비스를 이용할 수도 있습니다.

Git 사용법 🔨

git의 여러 명령어를 통해서 git의 사용법을 알아보려고 합니다!

git init

처음 git을 사용할 때 필요한 명령어입니다. 최초 한 번만 입력하면 됩니다.

git 명령어 위주의 설명이기 때문에 github 저장소를 생성하는 작업은 스킵했습니다.

계정 정보 입력

git config --global user.email <myEmail>
git config --global user.name <myName>

수정

git config --global --edit

git status

• git으로 관리되고 있는 파일의 상태를 확인할 수 있다.

git의 3가지 상태

modified

• 파일을 수정하면 그 파일은 modified 상태가 된다.

staged

• 변경된 파일을 git add 명령어를 통해서 stage area로 올리면 staged 상태가 된다.

committed

• staged 파일을 git commit -m <message>를 통해서 해당 파일을 committed 상태로 바꿀 수 있다.
• 여기까지 진행하고 git push가 일어나야 원격 저장소에 해당 내용이 반영된다.

untracked files

• 아직 git이 관리하지 않는 파일
• 보안에 위협이 되는 파일은 git으로 관리하지 않는 것을 권장

git init 명령어를 실행하고 새로운 파일을 추가하게 되면 untracked file이 추가됩니다.

git status 명령어를 통해 확인할 수 있습니다.

git add <fileName>

• modified 상태의 파일을 staged 상태로 변경
• 해당 파일을 stage에 올림 (staged 상태)
• git add . 명령어를 통해서 stage에 올라가지 않은 파일 모두를 stage에 올릴 수 있다.

새로 만든 파일을 해당 명령어로 입력하게 된 경우 위와 같은 화면을 볼 수 있습니다.

이미 git에서 관리하고 있는 파일이 수정된 경우에는 modified라고 파일명 앞에 나타납니다.

git restore <fileName>

• modified 상태의 파일을 수정 이전의 상태로 변경
• 모든 파일을 초기화하려면 git restore . 명령어 사용

git restore --staged <fileName>

git restore --staged <fileName>

• staged 상태의 파일을 modified 상태로 변경
• stage에 올라간 fileName을 modified 상태로 변경
• 새로 추가된 파일의 경우에는 untracked files로 변경 됨
• 모든 파일을 초기화하려면 git restore --staged . 명령어 사용

git rm

git rm <fileName>

• 원격저장소와 로컬 저장소 파일을 모두 삭제

git rm --cached <fileName>

• 로컬 저장소의 파일은 보존하고, 원격 저장소에 있는 파일만 삭제

.gitignore

• 해당 파일에 작성된 파일, 폴더는 git에서 관리하지 않음
• 매번 git rm 관련 명령어를 쓰지 않아도 된다.

git commit

git commit

• 해당 명령어만 입력하면 vim을 통해서 커밋 메시지 작성 가능

git commit -m "Commit Message"

• 보편적으로 사용하는 git commit 명령어
  

git commit <file> <file2> <file3> -m "Commit Message"

• 여러 파일을 선택적으로 커밋하고 싶을 때 사용

git commit -am "Commit Message"

• git add와 git commit 명령어를 한 번에 사용 가능
• 반복 작업을 줄여줄 수 있다.

커밋 메시지를 길게 입력하고 싶다면

git commit -a

명령어를 사용하면 됩니다.

git log

• 커밋의 목록을 볼 수 있음
• 커밋의 id, 시간, 커밋 메시지를 포함

git log

git shortlog

• 간략하게 git log 정보를 확인 가능

git log --oneline

• git shortlog 보다는 더 많은 정보를 포함해서 확인 가능

git show <commitId>

• 특정 <commitId>를 이용해서 수정 내용을 확인할 수 있다.

git diff

• 모든 코드의 수정 내용을 알고 싶을 때 사용한다.

git 입장에서는 코드가 수정되면 기존 작성된 코드가 삭제되고 새로 작성된 코드가 추가되는 개념입니다. 그래서 기존의 작성된 코드가 수정됐다고 생각하지 않습니다.

git diff <fileName>

• fileName의 수정 내용을 확인

git으로 협업하기 🤝

현재까지의 명령어는 지역 저장소에서 사용 가능합니다. 우리는 협업을 위해서는 github까지 사용해야 합니다.

원격 저장소 연결

git remote add <name> <url>

• name이라는 이름으로 url을 연결 (name은 url 별칭을 의미한다.)
• name과 url은 필수

git remote add origin https://github.com/iamaiden/git-practice

위와 같이 명령어를 사용할 수 있습니다. origin이라는 name으로 url을 연결한다는 의미입니다. 이후에는 url에 대신에 name을 사용하면 됩니다.

원격 저장소에 버전 내역 반영 (git push)

git push <name> <branch>

• git remote를 하고나면 기본적으로 master라는 브랜치가 생성 됨
• git push --help 를 입력했을 때 대괄호([])에 나오는 명령어는 옵션
• git push url별칭(ex. origin) url Branch(ex. master)

git push origin master

지역 저장소의 master 브랜치의 버전 내역을 원격 저장소의 master 브랜치에 반영합니다.

원격 저장소에서 내용 불러오기 (git pull)

git pull <remote> <branch>

• 협업 시 충돌을 막기 위해서 작업 전에 git pull 명령어로 시작

git pull origin master

원격 저장소의 master 브랜치의 버전 내역을 로컬 저장소의 master 브랜치에 반영합니다.

git reset

• 커밋을 초기화 시키고 싶을 때 사용

git reset HEAD~1
git reset --mixed HEAD~1

HEAD는 현재 커밋의 위치를 나타냅니다. 위의 명령어는 현재 커밋의 위치에서 한개의 커밋 내용을 뒤로 돌리는 의미를 가지고 있습니다. 두 명령어 모두 같은 기능을 수행합니다.

커밋 이후 해당 명령어를 사용하게 되면 파일들은 modified 상태로 변경됩니다. (committed → modified)

git reset --soft HEAD~1

--soft라는 옵션을 추가하게 되면 파일들이 staged 상태로 변경됩니다. (committed → staged)

git reset --hard <commitId>

<commitId> 이후 작성한 모든 커밋 내용을 삭제합니다.

git reset --hard HEAD~1

• committed 상태를 수정 이전 혹은 생성 이전 상태로 변경 (committed → 기존 상태)
• git reset HEAD~1 → git restore <fieName> 과정과 동일한 명령어 기능을 가지고 있다.

이미 github에 올라간 내용을 되돌리기 위해선 어떻게 해야 할까요?

git reset 명령어를 사용하게 되면 커밋 자체가 사라지기 때문에 되돌리려고 하는 내용을 다른 작업자가 알 수 없습니다. 그래서 되돌리는 내용도 표시할 수 있도록 git revert 명령어를 사용합니다.

git revert

• 되돌리려고 하는 커밋을 그대로 유지하고, 새로운 커밋을 통해서 되돌리는 기능
• 보통 협업할 때 revert 명령어를 주로 사용한다.
• 되돌리려고 하는 내용을 공유하기 위해서 사용한다.

git revert HEAD

git revert <commitId>

최근 커밋을 되돌리거나, <commitId> 를 통해서 커밋을 되돌릴 수 있습니다.

revert 명령어를 취소하는 것은 커밋을 되돌리는 것과 동일합니다.

git reset --hard HEAD~1 명령어를 사용하면 됩니다.

git branch

• 보편적으로 master 브랜치가 전체 프로젝트의 중심이 된다.
• 신기능 등을 개발할 때 새로운 브랜치를 이용해서 신기능을 개발할 수 있다.

git branch라고 입력하게 되면 현재 존재하는 브랜치의 목록을 나타냅니다.

브랜치 생성

git branch <branch>

브랜치 삭제

git branch -d <branch>

브랜치 이동

git checkout <branch>

• 입력한 브랜치로 작업 공간을 이동한다.

브랜치를 나눠서 사용하는 이유

신기능을 개발하다가 운영 이슈 혹은 버그가 발생하게 되면, 브랜치를 나누지 않았을 경우 개발하던 신기능을 모두 되돌려야 합니다.

하지만 브랜치를 나눠서 사용하게 되면 운영에서 사용하고 있는 브랜치를 master 브랜치에 두고, 신기능을 개발하는 브랜치를 따로 생성해서 작업하게 되면 운영 이슈가 발생했을 때 브랜치 이동을 통해서 서로 코드의 간섭을 받지 않게 됩니다.

운영 이슈를 master 브랜치에서 해결하고 다시 본인의 브랜치에서 신기능 개발을 이어갈 수 있습니다.

그렇기 때문에 항상 작업을 시작할 때는 git branch 명령어를 통해서 현재 브랜치의 위치를 확인하는 습관을 들이는 것이 좋습니다.

추가적으로 git pull origin <branch> 명령어를 이용해서 다른 작업자들이 작업한 내용을 동기화하고 작업을 진행하는 것이 좋습니다.

git merge

• 현재 브랜치에서 다른 브랜치의 변경 내역을 가져온다.

git merge <branch>

만약 develop 브랜치에서 master 브랜치의 변경 내역을 가져오고 싶다면, git checkout develop → git merge master 순서로 명령어를 입력하면 됩니다. merge 과정을 포기하고 싶다면 git merge --abort 명령어를 입력하면 됩니다.

git rebase

• 현재 브랜치에 다른 브랜치의 변경 내역을 가져오면서 base를 재설정한다.

git rebase <branch>

git merge의 경우에는 현재 브랜치에 다른 브랜치의 변경 내역을 가져오면서 새로운 커밋이 발생하게 되는데, git rebase의 경우에는 현재 브랜치와 다른 브랜치의 변경 내역을 시간 순서대로 반영하고, 새로운 커밋이 발생하지 않습니다.

하지만 많은 작업자들이 사용하는 브랜치의 경우 rebase 명령어를 사용하는 것은 위험합니다.

기존 작업자들의 커밋 히스토리가 변경되는 경우에는 각 작업자들은 떄에 따라 자신의 커밋을 다시 반영하거나 재작업을 해야할 수도 있습니다.

git rebase 진행 중 confilct가 발생하는 경우, git rebase --continue 명령어를 입력하면 됩니다.

rebase 과정을 포기하고 싶다면 git rebase --abort 명령어를 입력하면 됩니다.

conflict가 발생했을 경우

git merge나 git pull, git rebase 와 같은 명령어를 사용하다보면 conflict가 발생할 수 있습니다.

다른 작업자와 같은 코드를 수정하게 되서 나타나는 "충돌"입니다.

이러한 경우 우선적으로 해당 코드 내용을 수정합니다.

수정하지 않고 파일을 추가, 커밋, 푸시하게 되면 conflict가 발생한 부분은 각 브랜치에서 들어온 내용을 모두 반영하게 됩니다.

수정이 완료 됐다면 해당 파일을 add → commit → push 합니다.

git commit -am <commitMessage>
git push origin <branch>

git cherry-pick

• 다른 브랜치의 변경 내역을 가져오고 싶은 경우에 대부분 rebase, merge 명령어를 사용한다.
• 특정 변경 내역을 가져오고 싶을 때 cherry-pick 명령어를 사용한다.

1개의 커밋을 적용

git cherry-pick <commitId>

1개 이상의 커밋을 적용

git cherry-pick <commitId> <commitId>

범위를 이용해서 커밋을 적용

git cherry-pick <commitId>..<commitId>

앞에 입력한 <commitId> 부터 뒤에 입력한 <commitId> 이전의 모든 커밋을 적용합니다.

git stash

• 어느 브랜치에서 수정 작업을 진행하던 중 다른 브랜치로 이동하고 싶을 때 사용한다.
• 보통 작업을 진행하던 중 다른 브랜치로 이동하게 되면 에러가 발생하게 된다.
• 임시 저장소를 생성해서 해당 작업 내용을 저장한 뒤 브랜치를 이동한다.

임시 저장소 생성

git stash

• 작업 중인 내용이 임시 저장소에 저장이 되고, 현재 브랜치에는 수정 사항이 없어지게 된다.
• 이후 git checkout 명령어를 사용해서 다른 브랜치로 이동할 수 있다.

임시 저장소 목록

git stash list

• 저장된 내용을 목록으로 확인할 수 있다. 최근에 추가된 내용이 0번으로 추가된다.

저장 내용 반영

git stash apply

• 저장 내용을 현재 브랜치에 반영한다.

임시 저장소 삭제

git stash drop

• git stash apply 명령어를 사용하게 되는 경우 저장 내용은 반영하지만, 임시 저장소에 해당 내용이 삭제 되지는 않는다.

• 저장 내용 반영과 저장소 삭제를 동시에 진행하고 싶다면, git stash pop 명령어를 사용하면 된다.

git stash 명령어를 유용하게 사용하는 경우는 브랜치를 착각했을 때입니다.

develop 브랜치에서 작업해야 되는 기능을 브랜치를 확인하지 않고 master 브랜치에서 작업했다고 생각해봅시다.

이러한 경우에는 작업한 내용이 크지 않다면, 수정 사항을 git restore 명령어를 통해서 되돌리고 브랜치를 이동할 수 있습니다.

하지만 작업 내용이 많다면 이렇게 하기 쉽지 않을 것 입니다. 이러한 경우에는

git stash
git checkout develop
git stash pop

위와 같이 명령어를 입력하게 되면 모든 수정 사항이 develop 브랜치로 이동됩니다.

git stash pop 명령어를 사용했을 때, conflict가 발생하게 될 수 있습니다. 이러한 경우에는 동일하게 수정하고 반영하면 됩니다.

마무리

하나하나의 명령어는 조금 더 자세한 설명을 찾아봐야 되겠지만, 정리한 명령어를 가지고 git을 사용하시는데는 큰 문제가 없을거라고 생각합니다!

언젠가는 git에 대해서 잘 정리해놓고 싶은 생각이 있었는데 이렇게라도 정리를 하게 되서 뿌듯합니다. 👍

출처

• https://ko.wikipedia.org/wiki/%EA%B9%83%ED%97%88%EB%B8%8C
• https://velog.io/@donghoim/%EC%A0%95%EB%B3%B4%EC%B2%98%EB%A6%AC%EC%82%B0%EC%97%85%EA%B8%B0%EC%82%AC-36%EA%B0%95-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EB%B2%84%EC%A0%84-%EA%B4%80%EB%A6%AC-%EB%8F%84%EA%B5%AC
• https://cross-the-line.tistory.com/m/20
• https://www.youtube.com/watch?v=cEg9hiZax8U&list=PLcqDmjxt30RvjqpIBi4mtkK5LkzYtXluF

오늘은 꼭 enum을 사용하면 안되는 것인가..? 에 대해서 자세하게 알아보려고 합니다. 제가 속한 조직에서는 enum을 선택해서 사용했는데요! 결론적으로 enum을 선택해서 사용한 의견에 대해서도 알아보려고 합니다.

enum

enum은 열거형 변수로 정수를 하나로 합칠 때 편리한 기능입니다. 임의의 숫자나 문자열을 할당할 수 있으며 하나의 유형으로 사용해서 버그를 줄일 수 있습니다.

// 아무것도 지정하지 않은 경우에는 0부터 숫자를 매깁니다. 
enum MOBILE_OS {
  IOS, // 0
  ANDROID // 1
}

// 임의의 숫자나 문자열을 할당할 수도 있습니다
enum MOBILE_OS {
  IOS = 'iOS',
  ANDROID = 'Android'
}

enum은 타입스크립트가 자체적으로 구현하는 기능입니다.

enum과 트리 쉐이킹 (Tree-shaking)

enum을 사용하지 않는 것을 권장하는 것 중 제일 큰 이유가 tree-shaking입니다.

Tree-shaking이란?

• 사용하지 않는 코드를 삭제하는 기능
• 번들 크기를 줄여 페이지가 표시되는 시간을 단축할 수 있다.

enum을 사용하게 되면 tree-shaking이 되지 않습니다. 왜냐하면 타입스크립트가 자체적으로 구현했기 때문에 타입스크립트는 자바스크립트로 변환할 때 IIFE(즉시 실행 함수)를 포함한 코드를 생성합니다.

하지만 rollup과 같은 번들러는 IIFE를 사용하지 않는 코드라고 판단할 수 없어서 tree-shaking이 되지 않습니다. 결과적으로 사용하지 않는 코드들도 최종 번들에는 포함되어 있습니다.

enum과 enum을 대체할 수 있는 것

• enum
• const enum
• Union Types

enum

enum CountryCode1 {
  'Argentina' = 'AR',
  'China' = 'CN',
  'Korea' = 'KR',
}

장점

1. key 값에 의미 있는 값을 부여할 수 있습니다.
2. 타입에 enum을 지정하면 따로 key에 대한 타입을 만들지 않아도 돼서 편리합니다.
3. Object.keys, Object.entries를 이용해서 값들에 대한 순회가 편리합니다. (number타입의 value 사용하지 않을 때)
4. enum을 쓰는 쪽에서는 오타를 낼 확률이 0%가 됩니다. 무조건 enum 값으로 써야 하기 때문입니다.(number타입의 value 사용하지 않을 때)
5. value가 number 형일 때, 양방향 매핑이 가능합니다.

단점

1. tree-shaking이 되지 않습니다.
2. 자바스크립트로 변환되고 나면 비교적 용량이 커집니다.
3. number타입의 value가 있다면 문제가 발생합니다.
4. value가 number 형일 때, 양방향 매핑이 가능합니다.

const enum

const enum CountryCode2 {
  'Argentina' = 'AR',
  'China' = 'CN',
  'Korea' = 'KR',
}

장점

1. tree-shaking이 됩니다.
2. 자바스크립트로 변환되고 나면, 매우 적은 용량을 차지합니다.
3. key 값에 의미 있는 값을 부여할 수 있습니다.
4. enum을 쓰는 쪽에서는 오타를 낼 확률이 0%가 됩니다. 무조건 enum 값으로 써야 하기 때문입니다.(number타입의 value 사용하지 않을 때)

단점

1. Object.keys, Object.entries를 이용해서 값들에 대해 순회를 할 수가 없습니다.
2. –isolatedModules 옵션을 사용하면, 사용 불가합니다.
3. 타입스크립트 패키지를 만들고, 이를 다른 곳에서 사용한다면, 이를 타입용으로 사용할 수가 없습니다.
4. CRA, Next.js에서 사용 불가합니다.
5. babel 설정도 추가로 필요합니다.

Union Types

const CountryCode3 = {
  'Argentina': 'AR',
  'China': 'CN',
  'Korea': 'KR',
} as const

type CountryCode3Type = typeof CountryCode3[keyof typeof CountryCode3]  // 이렇게 별도의 union type을 지정해줘야 함

장점

1. tree-shaking이 됩니다.
2. 자바스크립트로 변환되고 나면, 매우 적은 용량을 차지합니다.
3. Object.keys, Object.entries를 이용해서 값들에 대한 순회가 편리합니다.
4. key 값에 의미 있는 값을 부여할 수 있습니다.

단점

1. 이것을 위한 별도의 union type을 만들어야 해서, 성가십니다.
2. 원래의 의도가 enum과는 다르기 때문에, 쓰기가 약간은 망설여집니다.

결론 👨‍⚖️

대부분의 enum을 사용하지 않는 것을 권장하는 이유는 tree-shaking이었습니다! 하지만 저는 우아한형제들이 고민한 enum에 대한 의견에 조금 더 공감이 됐습니다.

우아한 형제들이 enum을 선택한 이유

• tree-shaking이 되지 않는다고 해도, enum 선언부가 엄청나게 크지 않는 이상, 이런 정도의 용량 다이어트가 필요한지 의문이다.
• 번들러마다 tree-shaking이 가능하기도 하다. (rollup은 불가능, vite는 가능)
• 다른 대안에 대한 단점이 부각되어 보이고, 최종적으로 enum을 쓰되, enum의 단점을 최소화하고 장점을 극대화시키기 위해서 value는 string형으로 사용한다.

정도가 될 것 같습니다!

위의 설명된 이유에 추가적으로 오타가 날 확률이 없다는 것도 저한테는 매우 매력적인 장점이라고 생각했습니다. 조금 더 자세한 설명을 확인하고 싶다면 하단의 출처를 확인해주세요!

출처

• https://engineering.linecorp.com/ko/blog/typescript-enum-tree-shaking/
• https://techblog.woowahan.com/9804/

그래도 이전에 @typescript-eslint나 styleslint 등을 사용하면서 eslint를 그래도 잘 사용하고 있다고 생각하고 있었는데요! 매번 사용을 할 때마다 계속 헷갈려하는 제 모습을 보고.. 이해를 못하고 있다고 생각이 들었습니다.

매번 적용을 하다보면 궁금해 하는 질문은 공통적이었습니다.

1. eslint-config와 eslint-plugin의 제대로 된 차이점은 무엇인가?
2. extends, rule, recommended는 어떻게 해석하는가?
3. .eslintrc.js 파일은 어떤 방식으로 작성해야 하는가?

이렇게 적고보니.. 그냥 아예 lint를 모르는 사람 같았습니다.. 🤦‍♂️ 그래서 오늘은 다시 한 번 정리와 함께 더 이상의 이론은 공부하지 않겠다는 다짐으로 작성해보려고 합니다.

eslint란?

• 자바스크립트 코드에서 문제를 찾아주고 고쳐주는 정적 분석 도구
• 기본적으로 CRA로 리액트 프로젝트를 생성하게 되면 eslint-config-react-app이라는 설정이 세팅되어 있다.

정적 분석 도구... 정말 많이 들었던 것 같습니다.. ㅎ 그리고 CRA 과정에서 eslint 관련된 라이브러리가 설치 된다는 것을 처음 알았습니다.

plugin과 config

사실 eslint를 사용하면서 가장 구분이 잘 되지 않고, 제대로 이해하기 어려웠던 부분이었습니다.

예를 들면 eslint-plugin-import, eslint-config-prettier, eslint-plugin-prettier 이런식으로 점점 추가해서 사용하라고 이야기하는데.. 추가하면 할수록 뭐가 뭔지 점점 헷갈리게 됩니다.

오늘은 확실하게 구분지어서 개념을 정리해보겠습니다. 🪓

eslint-plugin-*

짧게 플러그인이라고 하겠습니다.

플러그인 패키지는 룰을 정리한 패키지입니다. 예를 들면 eslint-plugin-react라는 패키지는 리액트와 관련된 룰을 정의한 패키지입니다.

그렇다면 사용은 어떻게 할까요?

{
    "plugins": ["react"]
}

eslint 설정을 할 때 흔히 보던 명칭입니다. 하지만 이렇게 작성하면 아무런 동작을 하지 않습니다.. 🤯 위의 의미는 "나는 이제 eslint-plugin-react를 추가할거야!" 라고 하는 것과 동일합니다.

선언만하고 사용은 하지 않은 것이죠.. 그러면 해당 패키지를 사용하려면 어떻게 해야할까요? rules에서 관리를 해줘야 합니다.

{
    "plugins": ["react"],
    "rules": {
        "react/jsx-uses-react": error
    }
}

이런식으로 해당 플러그인에 대한 룰(규칙)을 직접 입력해서 사용할 수 있습니다.

하지만 이렇게 플러그인을 사용하려면 매번 모든 플러그인의 룰을 알고 있어야하고, 활용할 줄 알아야합니다. 그리고 사용할 모든 룰을 직접 작성해줘야 합니다.

하나의 플러그인만 사용한다면 모를까 대부분의 사람들은 여러 플러그인을 설치해서 사용합니다. 사실상 모든 룰을 다 숙지한다는 것은 매우 어렵습니다.

그렇기 때문에 대부분의 플러그인은 자체 설정을 제공합니다. 그 자체 설정이 recommended, strict, all 과 같은 단어입니다.

해당 플러그인에서 제공하는 자체 설정을 사용하려면

{
    "extends": ["plugin:react/recommended"]
}

위와 같은 코드로 작성해줘야 합니다. 흔히 보던 recommended라는 키워드가 나왔습니다.

그렇다면 여기서 궁금증이 생길 수 있습니다.

자체 설정은 뭐고.. 좀전에 플러그인은 plugins 안에서 사용한다고 했는데.. 왜 extends라는 영역에서 사용하는거지? 🤔

플러그인의 자체설정 (recommended, all, strict 등)

자체 설정은 플러그인에서 룰에 대한 세팅을 해놓고 제공하는 것을 의미합니다. 그리고 해당 플러그인에서 제공하는 자체 설정의 경우에는 extends 영역에서 사용해야 합니다. (하지만 왜 extends 영역에서 사용해야 되는지는.. 잘모르겠습니다.. 🥲)

// eslint-plugin-react/configs/recommended
'use strict';

const all = require('./all');

module.exports = Object.assign({}, all, {
  languageOptions: all.languageOptions,
  rules: {
    'react/display-name': 2,
    'react/jsx-key': 2,
    'react/jsx-no-comment-textnodes': 2,
    'react/jsx-no-duplicate-props': 2,
    'react/jsx-no-target-blank': 2,
    'react/jsx-no-undef': 2,
    'react/jsx-uses-react': 2,
    'react/jsx-uses-vars': 2,
    'react/no-children-prop': 2,
    'react/no-danger-with-children': 2,
    'react/no-deprecated': 2,
    'react/no-direct-mutation-state': 2,
    'react/no-find-dom-node': 2,
    'react/no-is-mounted': 2,
    'react/no-render-return-value': 2,
    'react/no-string-refs': 2,
    'react/no-unescaped-entities': 2,
    'react/no-unknown-property': 2,
    'react/no-unsafe': 0,
    'react/prop-types': 2,
    'react/react-in-jsx-scope': 2,
    'react/require-render-return': 2,
  },
});

// this is so the `languageOptions` property won't be warned in the new config system
Object.defineProperty(module.exports, 'languageOptions', { enumerable: false });

위와같이 recommended 설정에는 직접 입력해야하는 룰들이 이미 입력이 되어있습니다. 그리고 이미 플러그인을 포함하고 있습니다.

하지만 plugins이 안 보이실겁니다..! 그 이유는 all 자체 설정에서 플러그인을 포함하고 있고 해당 설정을 불러와서 다시 로직을 처리하기 때문에 plugins 영역을 recommended 설정에서 찾을 수 없습니다!

위의 코드를 보면 all config 설정을 불러와서 Object.assign() 함수를 통해서 recommended config 설정을 하는 모습을 볼 수 있습니다.

eslint-config-*

그렇다면 config 패키지는 무엇일까요? 😁

eslint-plugin 패키지들이나 룰들을 모아서 설정으로 만든 것이 eslint-config-* 패키지입니다.

eslint에 관심이 있으시다면 많은 분들이 보셨던 eslint-config-airbnb 패키지를 예를 들 수 있습니다. eslint-config-airbnb 패키지 내부에는 아래의 플러그인과 룰들을 조합해서 만든 설정 패키지입니다.

• eslint
• eslint-plugin-import
• eslint-plugin-react
• eslint-plugin-react-hooks
• eslint-plugin-jsx-a11y

{
    "extends": ["airbnb"]
}

사용할 때는 위와 같이 간단하게 사용할 수 있습니다.

parser

대부분 저처럼 eslint-plugin이나 eslint-config에 빠져서 지나치는 경우가 있습니다.

parser는 무엇일까요? 코드를 분석하기 위한 파싱 툴입니다. 기본 값은 espree 입니다. 오늘은 parser에 대해서는 자세하게 다루지는 않으려고 합니다..!

보통 자바스크립트에서는 @babel/eslint-parser를 사용합니다. 타입스크립트에서는 @typescript-eslint/parser를 사용합니다.

이번에 알게 된 사실인데 아래처럼 recommended 자체 설정을 사용하게 되면 @typescript-eslint/parser가 자동적으로 포함됩니다..!

{
    extends: ["plugin:@typescript-eslint/recommended"]
}

// typescript-eslint/packages/eslint-plugin/src/config/base.ts

export = {
  parser: '@typescript-eslint/parser',
  parserOptions: { sourceType: 'module' },
  plugins: ['@typescript-eslint'],
};

순간 @typescript-eslint조차도 plugin이라고 생각했던.. 저를 반성하며.. 🤦‍♂️ @typescript-eslint는 parser도 있고 플러그인도 있고, 자체 설정도 포함되어 있었던 것이죠.. ㅎ

정리

eslint-plugin

• eslint에 대한 룰만 정의한 패키지이다. (아직 사용한다고 말 안했다.)
• eslint 설정 파일의 plugins, extends 영역에서 사용 가능하다.
• 기본적으로 커스텀한 규칙을 모아서 제공하기 위해 만들어진다.
• 자체 설정(config)을 사용하지 않는다면 개인적으로 룰을 숙지하고 설정해줘야 한다.
• 자체 설정은 extends 영역에서 plugin:패키지이름/config이름으로 사용해야 한다.
• 자체 설정은 어떤 룰을 사용할 것인지도 설정이 되어 있고, 이미 eslint-plugin도 포함되어 있다.
• 네이밍은 기본적으로 eslint-plugin-*, @<scope>/eslint-plugin, @<scope>/eslint-plugin-* 식으로 사용할 수 있다.
• 플러그인의 환경 설정, 플러그인의 프로세서, 복수 개의 config를 포함할 수 있다.

eslint-config

• eslint-plugin 패키지들과 룰을 모아서 설정으로 만든 패키지이다.
• 일반적으로 eslint 설정 파일들을 공유하기 위한 목적으로 만들어진다.
• eslint 설정 파일의 extends 영역에서 사용해야 한다.
• 플러그인의 경우에는 자체 설정을 사용하려면 extends 영역에서 plugin:패키지이름/config이름으로 사용해야 하는데 eslint-config는 패키지 이름만 써주면 된다.
• 네이밍은 기본적으로 eslint-config-*, @<scope>/eslint-config, @<scope>/eslint-config-* 식으로 사용할 수 있다.

자신만의 규칙도 만들고 설정도 만들고 싶다면 eslint-plugin을 사용하거나 만드는 것을 추천합니다. 하지만 airbnb처럼 기존의 설정들을 모아서 공유하려는 목적이 강하다면 eslint-config를 사용하거나 만드는 것을 추천합니다.

마무리

다양한 eslint-plugin이나 eslint-config 패키지들에 관심을 가지면서 이렇게 정리를 해보게 되었습니다. 알고 쓰는 것과 모르고 쓰는 것의 차이는 크다고 생각합니다. 앞으로는 과거보다는 더 잘 알고 쓴다는 생각에 조금 더 뿌듯하긴 합니다. 😎

그리고 사용하다보니 불편한 점도 있었고, 커스텀해보고 싶다는 생각도 들었습니다.

시간이 될 때 개인적으로 eslint-plugin, eslint-config 패키지 하나씩 만들어 보려고 합니다. 개인적으로 프로젝트 만들때마다 설정하는 것도 귀찮기도하고.. 회사에서 협업용으로 하나 만들어서 가져가보려고 합니다!

출처

• https://github.com/jsx-eslint/eslint-plugin-react/blob/master/index.js
• https://github.com/jsx-eslint/eslint-plugin-react/blob/master/configs/recommended.js
• https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/src/configs/base.ts
• https://velog.io/@yrnana/ESLint-%EC%95%8C%EA%B3%A0-%EC%93%B0%EC%9E%90
• https://younho9.dev/sharing-eslint-config

오늘은 $와 _의 의미를 자세하게 알아보려고 합니다. 이전에 제이쿼리를 사용하면서 $는 자주 볼 수 있었는데요. _는 조금 생소하기도 하고, 정확한 의미를 정리해두는 게 좋을 것 같아서 내용을 찾아 보았습니다.

요즘 많은 부분에서 공부가 필요하다고 느낍니다.. 😂

$와 _는 둘 다 자바스크립트의 식별자입니다. 식별자는 이름과 같은 방식으로 객체를 식별한다는 의미를 가지고 있습니다. 여기서 객체는 변수, 함수, 속성, 이벤트 및 객체 등이 포함됩니다.

$와 _는 다른 특수기호와 같은 방식으로 처리되지 않습니다. 대신 알파벳 문자처럼 취급됩니다. 그리고 두 식별자 모두 강요가 아닌 일종의 관례로 사용되고 있습니다. $, _의 후속 문자에는 숫자도 포함될 수 있습니다.

$(doller) 식별자

$ 식별자의 용도는 크게 2가지로 나눌 수 있습니다.

• document.getElementById() 함수의 바로가기
• 템플릿 스트링

$ 식별자는 일반적으로 document.getElementById() 함수의 바로가기로 사용됩니다. 함수의 이름이 매우 길고 자주 사용되기 때문에 바로 가기로 사용 됐습니다.

document.getElementById() 함수는 HTML 요소에서 id를 알아내는 함수입니다.

$ 식별자를 사용할 때는 별도의 라이브러리를 사용하지 않아도 됩니다. 하지만 $를 document.getElementById() 함수의 바로가기로 사용하기 위해서는 별도의 $() 함수 정의가 필요합니다.

function $(id) {
  return document.getElementById(id);
}

<div id="myDiv">
  Hello World!!
</div>

const element = $(myDiv); // == document.getElementById('myDiv')

$() 함수가 정의되고 나면 위와 같이 사용할 수 있습니다. 추가적으로 $ 식별자를 이용해서 템플릿 스트링으로 사용할 수 있습니다. 백틱을 사용할 때 $ 식별자를 이용해서 변수명을 그대로 보여줄 수도 있습니다.

const name = "aiden";
const age = 20;

console.log(`이름은 ${name}이고, 나이는 ${age}입니다.`)

바닐라 자바스크립트, 제이쿼리를 거쳐서 리액트를 사용하고 난 뒤부터는 아무래도 $ 식별자를 사용하는 일이 매우 줄어든 것 같습니다.

그나마 템플릿 리터럴에 많이 사용했던 것 같네요 😁

_(underScore) 식별자

_ 식별자는 변수나 함수 앞에 접근제어자 private 특성이 적용되어야 될 때 명시하는 역할로 사용됐습니다. 그래서 public과 private를 즉시 식별할 수 있는 가장 빠르고 쉬운 방법입니다.

자바스크립트에서는 별도의 public, private가 없기 때문에 일종의 코딩 컨벤션으로 사용 됐습니다. 그래서 public, private 키워드 없이 필드나 메소드를 식별할 때 유용하게 사용할 수 있었습니다.

ES2019

이전의 자바스크립트 클래스에서는 기본적으로 접근지정자 키워드가 존재하지 않았습니다. 그래서 모든 필드와 메소드는 public으로 설정되어 있어서 쉽게 접근할 수 있었습니다.

하지만 ES2019부터 # 기호를 추가해서 클래스 내부에서 private하게 메소드와 필드를 선언할 수 있습니다. 그리고 _ 기호를 이용해서 protected 필드를 모방해서 사용합니다.

마무리

_ 식별자를 찾아보면서 ES2019 스펙에 대해서도 공부가 필요하다고 느꼈습니다! 📚

Class에 대한 정리를 하려고 했는데 해당 스펙을 기준으로 어떠한 차이점이 있는지 자세하게 보는 것도 좋을 것 같습니다. 본인이 _ 식별자를 이용해서 Class 문법을 작성하고 있다면 자바스크립트 스펙을 확인하고 정식 기능을 사용할지에 대한 고민을 해보는 것도 좋을 것 같습니다.

코딩 컨벤션처럼 관용적인 내용보다는 정식으로 지원하는 기능을 사용하는 것이 더 좋을수도 있지 않을까? 라는 생각도 드네요!

출처

• https://ko.eferrit.com/javascript%EC%9D%98-%EB%8B%AC%EB%9F%AC-%EA%B8%B0%ED%98%B8-%EC%99%80-%EB%B0%91%EC%A4%84-_/

• https://velog.io/@yes3427/JavaScript-Dollar-Sign-and-Underscore

• https://mkonji23.tistory.com/24

• https://leftday.tistory.com/70

• https://bamtory29.tistory.com/entry/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%EC%9D%98-protected%EC%99%80-private-%EB%A9%A4%EB%B2%84

any 혹은 unknown 두 타입은 잘 사용하지 않지만, 어떤 타입을 사용하는게 맞는지에 대한 내용을 다루는 컨벤션이 많았습니다. 그 중에서 우아한형제들 기술블로그에서 해당 내용에 대해서 굉장히 자세하게 작성해주신 내용을 공부 겸 정리해보려고 합니다. 덕분에 any vs unknown을 비롯해서 컨벤션과 관련해서 많은 지식들을 배울 수 있어서 좋았습니다. 👍

짧은 결론은 두 타입 모두 사용하지 않는 것이 좋습니다. 🙅‍♂️

하지만 왜 사용하지 않아야 하는지, 어떠한 차이가 있는지는 알고 사용하지 않는 것이 좋을 것 같습니다

any vs unknown

any

• tsconfig에서 strict를 true로 설정하거나, noImplicitAny를 true로 설정하면, 각종 변수에 타입을 지정하지 않았을 때 에러가 발생한다.
• 타입스크립트에서 기본적으로 타입 추론을 하는데, 추론한 근거가 없으면 암시적으로 any로 할당된다.
• strict 를 지정하지 않으면 계속 any가 쌓이게 될꺼고 anyScript가 될 수 있다.
• 이러면 자바스크립트를 쓰는 것과 다르지 않아서 권장하지 않는다.

unknown

• unknown도 마찬가지로 어떠한 타입이든 다 올 수 있지만, 이후 동작에 대한 제어가 가능하다.

  const sayNumber = (num: number) => {
  console.log('num: ', num)
  }
  

const sum = (a: any, b: any): any => a + b const three = sum(1, 2) sayNumber(three)

const minus = (a: any, b: any): unknown => a - b const five = minus(7, 2) sayNumber(five) // 'unknown' 형식의 인수는 'number' 형식의 매개 변수에 할당될 수 없습니다.

### 코드 설명

- `three`의 타입은 `any`
- `five`의 타입은 `unknown`
- `sayNumber` 함수에 `three`를 넣게 되면 3이 출력
- `sayNumber`에 `five`를 넣게 되면 `unknown` 타입은 `number` 타입의 매개변수에 할당할 수 없음



`sayNumber(five)`를 제대로 사용하기 위해서는

- `minus` 함수의 타입을 `number`로 명확하게 지정한다.
- `five`를 `as number`로 타입 단언을 한다.

의 방식을 이용할 수 있습니다.



물론 이렇게 하는 것보다 제네릭을 사용하는게 일반적입니다.
`any`, `unknown` 모두 아무 타입이나 들어갈 수 있지만, `unknown`은 사용하는 쪽에서 처리를 강제해서 안전하게 사용할 수 있게 해줍니다



### `unknown`의 역할

- 해당 타입으로 지정된 값을 사용할 때가 되면 그 타입이 어떤 타입인지 명확히 알아야 사용할 수 있게 막아주는 역할을 합니다.



### `unknown`을 사용해야 하는 상황
- 적은 상황이지만 `unknown`은 예제와 같이 사용할 케이스가 있다.
```typescript
const isNil = (param: unknown): boolean => param === null || param === undefined

param을 받아서 null인지 undefined인지 확인해서 true/false를 반환하는 함수입니다.

단순히 null인지 undefined인지 체크만 하면 되기 때문에 어떠한 타입이 들어올지 몰라도 됩니다. 이때는 any를 사용할수도 있습니다. 프로젝트 설정에 따라서 any를 아예 사용하지 못하게 하는 경우가 있는데 이러한 경우에 unknown 타입이 적절하다고 생각합니다.

unknown 사용 예시

function prettyPrint(x: unknown): string {
  if (Array.isArray(x)) {
    return "[" + x.map(prettyPrint).join(", ") + "]"
  }
  if (typeof x === "string") {
    return `"${x}"`
  }
  if (typeof x === "number") {
    return String(x)
  } 
  return "etc."
}

x를 any로 했을 경우 map(), join()을 사용할 수 있는데 unknown일 때 x가 배열인 경우에만 map(), join()을 사용할 수 있도록 강제해줍니다.

결론

• any는 아무때나 쓸 수 있지만, 타입스크립트를 쓰는 의미가 없게 되버릴 수 있다.
• unknown을 어쩔 수 없이 써야할 상황이 있을 수 있으나, 이를 사용하는 쪽에서 방어처리를 해서 안전하게 사용이 가능하다.

누군가는 다른 의견이 있을 수 있습니다.

이러한 내용에 대해서는 100% 정답이 없는 것 같습니다. enum, 세미콜론(;) 사용, any vs unknown 처럼 다양한 의견이 나올 수 있죠.

자신만의 확실한 의견이 있다면 어떠한 방식이든 문제가 되지는 않는 것 같습니다! 💪

출처

• https://techblog.woowahan.com/9804/#toc-2