작은 일에 크게 놀랄 필요 없이 새로운 피면 규칙을 첨가하다

linter는 코드의 질을 유지하고 인코딩 팀의 약속을 지키는 데 매우 유용하지만, 코드 라이브러리에 현재 위반된 새로운 규칙을 어떻게 추가합니까?소수의 위반 행위나 위반 행위가 자동으로 복구될 수 있다면 규칙을 추가하기 전에 복구하는 것은 쉬울 수 있지만 수백 개의 위반 행위가 있다면?

사례 연구

만약 우리가 linting에 CI를 설정하고 ESLint 규칙 import/extensions 을 추가하여 가져오는 모든 파일의 확장자를 확보하기를 원한다면.우리가 사용할 수 있는 몇 가지 옵션을 살펴보고, 각 옵션의 장단점을 고려합시다.

옵션 1: 모든 위반 복구

첫 번째 사용 가능한 옵션은 새 lint 규칙에 나타난 모든 위반 행위를 복구하는 것입니다.

설정

먼저 새 규칙을 추가합니다.

diff --git a/.eslintrc.json b/.eslintrc.json
   ...
   "rules": {
+    "import/extensions": ["error", "always"]
   }

현재 lint 오류가 있습니다. 실패한 CI 없이 주 지점으로 통합할 수 없습니다. 따라서 통합하기 전에 모든 오류를 복구합니다.시간이 걸리지만 이 과정은 매우 간단하다.코드 라이브러리의 모든 lint 규칙을 검사하고 복구합니다. 이 예에서는 파일 확장자가 없는 가져오기마다 파일 확장자를 추가합니다.

찬성 의견

코드 라이브러리 100% 새 규칙 준수!lint를 위반하는 어떠한 상황도 없다. 미래의 모든 사람들은 이 규칙을 따라 변경할 것이다. 그렇지 않으면 구축에 실패한 분노에 직면하게 될 것이다.시간과 동력이 그것을 완성할 때, 이 전략은 매우 좋다.

기만하다

수백 개의 자동 복구가 불가능한 경고가 나타날 때, 이 정책은 새로운 규칙에서 가치를 얻는 것을 지연시키거나 막을 것입니다.

옵션 2: 새 규칙을 경고로 설정

오류가 아닌 경고로 새 규칙을 추가하는 것은 어떻습니까?

설정

먼저 새 규칙을 추가합니다.

diff --git a/.eslintrc.json b/.eslintrc.json
   ...
   "rules": {
+    "import/extensions": ["warn", "always"]
   }

우리 망했어!

찬성 의견

설치가 매우 간단합니다. 개발자가 ESLint 플러그인을 사용하면 편집기에서 이 규칙을 볼 수 있는 새로운 lint 규칙이 생겼습니다.

기만하다

새로운 규정을 진정으로 집행할 수 있는 것은 없다.이것은 경고일 뿐입니다. 코드 라이브러리에 수백 개의 다른 경고가 있을 수 있습니다.경고는 개발자가 눈치채지 못한 채 쌓인다.

완화 조치

ESLint에는 최대 수의 경고를 적용할 수 있는 CLI 옵션 --max-warnings 이 있습니다.불행하게도, 모든 기존 경고를 복구할 때, 최신식으로 유지해야 합니다. 그렇지 않으면, 모든 복구는 미래의 경고를 위해 시간을 남길 것입니다.

옵션 3: ESLint 오류 억제

우리는 기존의 규칙 위반 행위를 억제하여 새로운 규칙을 집행하는 동시에 기존 문제를 해결하는 직접적인 비용을 피할 수 있다.

설정

우리는 새로운 규칙을 추가한 다음에 모든 lint 규칙 위반에 eslint-disable-next-line을 추가할 것이다.
먼저 lint 변경 사항을 옵션 1과 동일한 .eslintrc.json에 추가합니다.

diff --git a/.eslintrc.json b/.eslintrc.json
   ...
   "rules": {
+    "import/extensions": ["error", "always"]
   }

그리고 suppress-eslint-errors 을 실행합니다.suppress-eslint-errors 패키지는 추가된 억제 사항을 수동으로 수정해야 한다고 지적합니다.ESLint와 관련되지 않은 설정인 경우 suppress-eslint-errors의 대체 품목을 찾거나 수동으로 작업을 완료해야 할 수도 있습니다.

npx suppress-eslint-errors src/**/*.{ts,tsx} --message="TODO: add extension"

diff --git a/src/App.test.tsx b/src/App.test.tsx
 import { render, screen } from '@testing-library/react
+// TODO: add extension
+// eslint-disable-next-line import/extensions
 import App from './App';

See this example of a suppress violations diff for the changes needed to add this to a small project.

찬성 의견

기존의 고장을 억제하면 lint 경고를 깨끗하게 유지할 수 있고, 새로운 규칙을 위반하지 않고 미래의 변경을 실행할 수 있습니다.너는 과거로 돌아가 억제된 규칙 위반 행위를 체계적으로 복구할 수 있다.

기만하다

경고를 억제하는 줄은 코드의 소음을 낮추었다.또한 개발자가 lint 규칙을 위반하는 코드를 작성할 때 eslint-disable을 추가하여 lint의 효율을 낮출 수 있다.

옵션 4: 새 규칙만 사용하여 새 변경 내용 삭제

약간의 추가 작업과 약간의 복잡한 설정을 통해 우리는 기존의 규칙 위반 행위를 무시하는 linting을 실현할 수 있으며, 동시에 새로운 변화에 대해 책임을 질 수 있다.나는 가장자리 털실이라고 부르는 것을 좋아한다.
reviewdog(또는 pronto, 루비를 좋아한다면)과 같은 도구를 사용하면 GitHub 검사를 설정하여 어떤 lint 위반으로 우리의 PRs를 주석할 수 있습니다.

설정

이제 별도의 ESLint 구성이 두 개 있습니다."main"ESLint 구성(.eslintrc.json)에 새 규칙이 추가되었습니다.이것은 편집기와reviewdog에서 실행하는 기본 설정입니다.
우선, 링크 변경 사항을 .eslintrc.json에 추가합니다. 옵션 1과 같습니다.

diff --git a/.eslintrc.json b/.eslintrc.json
   ...
   "rules": {
+    "import/extensions": ["error", "always"]
   }

두 번째 ESLint 구성은 CI에 새로 추가된 규칙을 의도적으로 비활성화합니다.eslint --config=.eslint-ci.json을 사용하여 링크 작업 흐름에 위치를 지정합니다.

// .eslintrc-ci.json
{
  "extends": ".eslintrc.json",
  "rules": {
    "import/extensions": "off"
  }
}

reviewdog eslint action을 사용하여 새 GitHub 작업 흐름을 추가하여pull에 요청한 새로운 규칙을 실행합니다.

# .github/workflows/reviewdog.yml
# Modified from reviewdog action eslint README
# https://github.com/reviewdog/action-eslint#githubworkflowsreviewdogyml
name: reviewdog
on: [pull_request]
jobs:
  eslint:
    name: runner / eslint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Lint Typescript Changes 👕
        uses: reviewdog/action-eslint@v1
        with:
          reporter: github-pr-check
          eslint_flags: "--config=.eslintrc.json src/**/*.{ts,tsx}"

See this example reviewdog setup diff for the changes needed to add this to a small project.

결과는요

현재, 우리의 변경이 모든 lint 규칙 (기존의 규칙 포함) 을 위반할 때마다, 우리는 인출 요청에서 경고를 받을 것입니다.

찬성 의견

.eslintrc.json을 더욱 엄격한 설정으로 설정하면 기본적으로 모든 새로운 통합이 이 설정을 따를 수 있습니다.CI와 같은 .eslintrc-ci.json의 모든 용도를 명시적으로 지정할 수 있습니다.
이런 설정은 코드 심사 통합을 포함하는 또 다른 장점이 있다. 새로운lint 규칙이 어떻든지 간에 이것은 유익하다.이것은 모든 새로운 규칙이 두 줄로 바뀌어야 한다는 것을 의미한다. 한 줄은 .eslintrc.json의lint 규칙에 사용되고, 다른 한 줄은 .eslintrc-ci.json의 비활성화에 사용된다.

기만하다

이 옵션의 설정은 더욱 복잡하며 CI 스택에 신기술을 추가했습니다.새로운 create-react-app에서 이 작업의 구축 시간은 3분이며 프로젝트 크기에 따라 증가할 수 있습니다.

결론

100% 호환되는 코드 라이브러리를 갖추는 것은 좋지만 모든 위반 행위를 즉각 복구하는 것은 불가능하다.가능한 한 새로운 lint 규칙을 추가하는 작업량을 줄이면 당신의 팀이 미래의 최선의 실천을 받아들이고 실시할 수 있도록 하는 데 도움이 됩니다.
새로운 규칙을 사용하지 않으려는 스크립트를 실행하면 이 문제를 빨리 해결할 수 있지만, 미래의 모든 링크 규칙은 마찬가지입니다.두 개의 lint 설정을 사용합니다. 약간의 복잡한 초기 설정이 필요하지만, 같은 장점을 제공하고, 새로운 규칙을 쉽게 추가할 수 있습니다.이것을reviewdog나pronto와 통합하면 코드 심사에서 새로운 실천을 더욱 쉽게 장려할 수 있다.