품질을 최우선으로! JavaScript 프로젝트에서 GitHub 워크플로로 코드를 린트하는 5가지 쉬운 단계

Wojciech Bak

코드 품질은 특히 장기적인 관점에서 효율적으로 작업하고자 할 때 개발 프로세스에서 매우 중요한 부분입니다. 전체 애자일 방법론을 포함하여 많은 접근 방식과 모범 사례가 있지만, 대부분은 최소 6명이 수행하는 대규모 엔터프라이즈 프로젝트와 관련이 있습니다.

다음과 같은 경우 어떻게 해야 하나요? 프로젝트 가 작거나 고객이 더 투자할 가치가 있는지 아직 잘 모르시나요? 분명히 프로젝트의 MVP 단계, 코드 스타일링이나 단위 테스트는 최우선 순위가 아닙니다. 투자자는 일반적으로 좋은 제품 작동한다면 테스트가 필요 없겠죠?

사실, 저는 다음과 같은 경험이 있습니다. 처음부터 앱 구축모범 사례를 처음부터 사용하지 않더라도 말이죠. 일부 비즈니스 상황에서는 투자자의 예산 계획과 개발자의 "있으면 좋은" 목록 사이에서 타협점을 찾아야 했습니다. 다행히도 GitHub를 사용하면 코드 품질과 관련된 대부분의 일반적인 문제를 몇 분 안에 해결할 수 있습니다.

이 글에서는 Node.js 환경에서 GitHub 워크플로우를 사용하여 코드베이스를 표준화하는 방법을 보여드리겠습니다.

시작하기 전에 몇 가지 가정이 필요합니다:

NPM 및 Linux 콘솔에 익숙합니다.
스타일 전처리기, 모듈 로더, 번들러 등에 대한 경험이 있습니다.
린터의 용도를 잘 알고 있고 프로젝트에 사용하고 싶으시죠?

1. 일반적인 JavaScript 프로젝트 구조

다음과 같은 JS 프레임워크를 사용해 본 적이 있다면 Vue 또는 React와 같은 몇 가지 공통점을 쉽게 찾을 수 있습니다:

/src 디렉토리에 모든 JS 로직과 컴포넌트를 저장합니다,
/test 디렉터리에서 단위 및 e2e 테스트를 수행합니다,
/자산 디렉토리에 스타일, 이미지 등을 저장합니다.

우리가 이야기하고 있더라도 JavaScript 프로젝트에서 작업하고 있습니다. 노드 환경이 있으므로 당연히 다음과 같은 노드 항목도 있어야 합니다. package.json, package-lock.json 그리고 /node_modules 카탈로그를 루트 디렉토리에 저장합니다.

이 모든 것이 제자리에 있습니다. 컨벤션. 프레임워크는 몇 가지 합리적인 규칙을 제공하기 위해 만들어졌기 때문에 일반적으로 초기 디자인 패턴에 대해서는 신경 쓸 필요가 없습니다. 이 예제에서는 몇 가지 접근 방식을 설명하고자 하므로 Vue CLI와 같은 즉시 사용 가능한 솔루션을 적용하지 않겠습니다.

이 모든 마법의 보푸라기 스크립트 아래에 무엇이 숨어 있는지 알아볼 시간입니다!

2. 일반적인 노드 프로젝트 확장

고품질 솔루션을 제공하기 위해 새 프로젝트를 설정할 때 가장 먼저 시작해야 하는 것은 린터입니다. 두 가지 린터에 집중해 보겠습니다. 스타일용 스타일린트(*.scss) 및 소스 파일용 ESLint(*.js). 이 두 가지 린터는 모두 NPM에서 사용할 수 있으며 구성이 매우 쉽습니다. 린터를 사용하려면 설치 프로세스를 거쳐 구성 파일을 추가하고 프로젝트 스크립트를 정의해야 합니다. 단계별로 해보겠습니다.

3. 스타일린트 추가하기

노드 환경에서 스타일린트를 설치하는 방법은 매우 간단합니다. 에 따르면 공식 문서를 실행하기만 하면 됩니다:

엔피엠 설치 --save-dev 스타일린트 스타일린트-config-standard

를 클릭하고 완료될 때까지 기다립니다.

스타일린트 구성 표준 는 기본 린팅 규칙 세트를 제공하며 필요에 더 적합한 패키지로 대체할 수 있습니다(예. 에어비앤비 스타일). 그런 다음 새 숨김 파일을 만듭니다. .stylelintrc.json는 미리 정의된 규칙을 로드하는 Stylelint 구성 파일입니다:

{
    "확장": "스타일린트-구성-표준"
}

현재 누락된 유일한 것은 SCSS 파일을 린팅하기 위해 package.json 파일에 선언된 일부 NPM 스크립트(또는 스크립트)입니다. 제 제안은 이렇습니다:

"스크립트": {
    "lint:scss": "스타일린트 '**/*.scss' --syntax scss -f verbose --color",
    "lint:scss:fix": "stylelint '**/*.scss' --syntax scss --fix -f verbose -color"
}

보시다시피, 저는 다음과 같은 스크립트를 선언했습니다. -fix 옵션 - 리포지토리에 변경 사항을 푸시하기 전에 사용하는 옵션입니다.

기억하세요 - 다음을 사용하는 것은 나쁜 습관입니다. -fix 를 CI 흐름에 포함하지 않으면 프로덕션에 전달하는 코드가 리포지토리에서 올바르게 스타일이 지정되지 않기 때문입니다. 그렇기 때문에 두 스크립트가 모두 필요합니다.

파일을 생성하여 린터를 테스트해 보겠습니다. /assets/scss/styles.scss 와 같은 일부 콘텐츠가 있습니다:

body {
                    배경색: #fff;
}

npm 실행 린트:SCSS

콘솔에 다음과 같은 내용이 표시될 것입니다:

> 스타일린트 '**/*.scss' --syntax scss -f verbose --color

assets/scss/styles.scss

2:21 ✖ 2칸 들여쓰기 예상 들여쓰기 들여쓰기

소스 1개 확인

~/Codest/Projects/github-workflow-demo/assets/scss/styles.scss

1 문제 발견

심각도 수준 "오류": 1

들여쓰기: 1

npm 오류! 코드 엘리프 사이클

npm ERR! errno 2

npm ERR! [email protected] lint:scss: `stylelint '**/*.scss' --syntax scss -f verbose --color`

npm ERR! 종료 상태 2

이것은 실제로 린터가 작동한다는 것을 의미합니다!

출력에는 오류를 일으키는 줄이 정확히 표시되고 해결해야 할 문제가 설명되어 있습니다. 일부 문제는 개발자의 판단이 필요하기 때문에 자동으로 수정할 수 없지만 대부분의 경우 동일한 명령을 -fix 옵션이 있으므로 실행해 보겠습니다.

npm 실행 lint:scss:fix

이제 오류가 발견되지 않은 녹색 출력이 표시됩니다:

스타일린트 '**/*.scss' --syntax scss --fix -f verbose --color


소스 1개 확인

/Users/wojciechbak/Codest/Projects/github-workflow-demo/assets/scss/styles.scss

0 문제 발견

4. ESLint 추가

이 단계는 이전 단계와 거의 동일합니다. ESLint를 설치하고, 몇 가지 기본 규칙 세트를 정의하고, 호출 가능한 두 개의 NPM 스크립트(하나는 CI용, 하나는 프리푸시용)를 선언하겠습니다. 시작해 보겠습니다!

일상 업무에서 NPM을 사용하는 경우 ESLint를 전역에 설치하고 싶을 수도 있습니다. 그렇지 않은 경우 다음에서 설치 지침을 확인하세요. 공식 문서.

npm 설치 -g eslint

컴퓨터에서 eslint 명령을 사용할 수 있으면 프로젝트에서 이 명령을 실행하면 됩니다:

eslint --init

터미널에 표시되는 추가 지침에 따라 다음과 같이 몇 가지 프로젝트 결정을 내리세요:

자바스크립트 또는 TypeScript
에어비앤비 스타일 또는 구글 스타일
구성 유형(JSON 파일, JS 파일 또는 인라인의 package.json)
ES 모듈(가져오기/내보내기) 또는 요구 구문

이 자리에서 Prettier라는 코드 포맷터에 대해 한 마디 쓸 가치가 있습니다. 완전히 표준화되어 있으며 대부분의 코드 편집기(예: VS Code)와 호환됩니다. Prettier는 사전 정의된 코드 스타일링 규칙 세트를 많이 제공하고 린터와 함께 작동하며 코드의 최고 품질을 추구하는 데 큰 도움이 될 수 있습니다. Prettier가 정확히 무엇인지 이해하려면 다음을 방문하세요. 비교 를 공식 문서에서 가져옵니다.

완료되면 ESlint 구성 파일(예 .eslintrc.json이전에 선택한 항목에 따라 다름)가 루트 디렉토리의 .stylelintrc.json 이전에 생성되었습니다.

이제 다음에서 스크립트를 정의해야 합니다. package.json 파일과 동일합니다:

"스크립트": {
    "lint:js": "eslint '**/*.js' --ignore-pattern node_modules/",
    "lint:js:fix": "eslint '**/*.js' --ignore-pattern node_modules/ --fix"
}

축하합니다! 이제 ESLint를 바로 사용할 수 있습니다. 제대로 작동하는지 확인해 보겠습니다. 만들기 /src/index.js 파일에 콘텐츠를 추가합니다:

console.log("something");

린터를 실행합니다:

npm 실행 lint:js

출력은 다음과 같이 표시되어야 합니다:

> eslint '**/*.js' --ignore-pattern node_modules/

~/Codest/Projects/github-workflow-demo/src/index.js

1:1 경고 예기치 않은 콘솔 문 no-console

1 문제(오류 0, 경고 1)

이 경고는 사용 후에도 사라지지 않습니다. -fix 옵션은 린터는 잠재적으로 의미 있는 코드에 영향을 미치지 않습니다. 코드 스타일링에만 사용됩니다.공백, 줄 바꿈, 세미콜론, 따옴표 등을 포함합니다.

5. GitHub 워크플로 정의하기

GitHub 워크플로 는 꽤 잘 문서화되어 있습니다. 이에 대해 더 자세히 알아보고 싶으시다면 지금부터 원격 리포지토리(물론 GitHub에서 호스팅)로 푸시한 후 코드를 린트하는 간단한 워크플로우를 구현해 보겠습니다.

만들기 /.github/workflows 디렉토리와 새 코드 품질 워크플로.yml 파일로 정의해야 하므로 GitHub 워크플로우를 YAML 파일로 정의해야 합니다.

제대로 된 워크플로를 실행하려면 몇 가지 질문에 답해야 합니다:

워크플로를 언제(푸시, 풀 리퀘스트, 병합 등) 실행하고 싶나요?
일부 상황(예: 브랜치 마스터에게 푸시)을 제외하길 원하나요?
명령을 올바르게 실행하려면 어떤 환경을 설정해야 하나요(이 예제에서는 노드)?
종속성을 설치해야 하나요? 그렇다면 어떻게 캐시해야 하나요?
확인을 완료하려면 어떤 단계를 거쳐야 하나요?

몇 가지 고려 사항과 몇 시간 동안의 문서 예제 작업 후 .yml 파일은 다음과 같이 보일 수 있습니다:

이름: 코드 품질

켜기: '푸시'

jobs:
  코드 품질:
    이름: 린트 소스 코드
    실행 중: 우분투 최신 버전
    steps:
    - 사용: actions/checkout@v1

    - 이름: 설정 노드
      사용: actions/setup-node@v1
      with:
        노드 버전: '12.1'

    - 이름: 캐시 종속성
      uses: actions/cache@v1
      with:
        경로: ./node_modules
        키: $(( runner.OS ))-의존성-$(( hashFiles('**/package-lock.json') ))
        복원 키: |
          $(( runner.OS ))-dependencies-$(( env.cache-name ))-
          $(( runner.OS ))-dependencies-
          $(( runner.OS ))-

    - 이름: 설치 종속성
      run: |
        npm 설치

    - 이름: 린트 파일
      run: |
        npm 실행 린트

깃허브는 우리에게 필요한 모든 환경을 제공합니다. 마지막 줄에서 다음 명령을 실행합니다. npm 실행 린트 이전에는 정의되지 않았습니다:

"스크립트": {
    "lint": "npm run lint:js && npm run lint:scss"
}

워크플로에서는 다음과 같이 사용하지 않습니다. 수정 명령어를 사용합니다.

이 모든 단계가 완료되면 풀 리퀘스트를 병합하기 전에 GitHub에서 이 멋진 결과물을 즐길 수 있습니다: