Type Script 프로젝트의 CI에서 하는 일

개요

최근 정년퇴직에 따라 타입스크립트 프로젝트의 CI/CD가 재평가를 진행 중이어서 주로 포스터에 대한 CI를 중심으로 무엇을 하는지(하고 싶은 것 포함) 소개한다.
각자 간단한 소개일 뿐이다.
그나저나 써보니 거의 TS 이외에는 다 가능하다.

tsc, prettier, eslint

기본아마도 대부분의 항목을 하고 있을 것이다.tsc 추가--noEmit 옵션 실행, eslint 추가--cache 및 --quiet 옵션 실행.prettier 옵션에 차이가 있을 때(=--list-different 적용되지 않는 파일이 있을 때) 오류가 발생합니다.
CI에서 웹팩 등으로 묶인 상태에서 이 일대를 불명확하게 진행하더라도 거기서 할 수 있어 하지 않은 경우도 있을 수 있다.

단원 테스트

그것도 기본이라고 생각해요.
Codecov 등을 사용하면 덮어쓰기 추적과 확장 가능한 코드가 덮어쓰기에 얼마나 큰 영향을 미치는지 등을 볼 수 있다.
하지만 며칠 전움츠러들다에는 코드코프를 싫어하는 사람이 있었을 것이다.
참고로 prettier면jest은 옵션이 변경된 파일과 관련된 단원 테스트만 실행할 수 있습니다.findRelatedTests에서 사용precommit hook하고 CI에서는 커버물을 측정하기 위해 모두 운행하는 경우가 많다.

취약한 패키지 검사

findRelatedTests 버그가 있는 매크로 패키지를 사용했는지 확인합니다.
Dependabot를 사용하는 프로그램이 많지만 채용할 때 확인하는 게 좋을 것 같아요.
CI의 경우 아래와 같이 HIGH 이상의 취약성을 등급에 포함시키면 오류가 발생할 수 있습니다.

/bin/bash -c 'yarn audit --groups dependencies --level high; [[ $? -ge 8 ]] && exit 1 || exit 0'

왜 이렇게 해키한 느낌이 들까? 이 아이슈.와 같이npm/yarn audit 값을 되돌리는 행위 때문이다.
아무래도 넣는 게 좋을 것 같은데, 최근에 React 근처에서 유명한 Dan Abramov씨이런 기사.가 투고해서 다시 보고 싶어요.

사용되지 않은 파일 확인 등

다음 방법을 사용하여 사용되지 않은 파일, 변수, 함수 등을 탐지할 수 있습니다.

https://github.com/pzavolinsky/ts-unused-exports

https://github.com/tomchentw/unused-files-webpack-plugin/

필요 없는 것을 계속해서 삭제하여 유지보수성을 높여라.
그나저나 웹팩은 5시리즈를 지원하지 않아서 유감입니다.

textlint

textlint는 텍스트 파일과 태그 파일을 위한 lint 도구입니다.에스린트처럼 다양한 규칙을 추가할 수 있다.또한 플러그인yarn audit을 추가하여 파일 등도 지원할 수 있습니다.
텍스트 파일도 코드처럼 일정한 일관성을 가지거나 표시의 흔들림을 배제할 수 있어 매우 유용하다.

$ textlint --rule terminology README.md

/path/to/README.md
  11:21  ✓ error  Incorrect usage of the term: “markdown”, use “Markdown” instead  terminology
  11:50  ✓ error  Incorrect usage of the term: “repo”, use “repository” instead    terminology
  13:40  ✓ error  Incorrect usage of the term: “repo”, use “repository” instead    terminology

Dead link 확인

체크 표시 파일의 링크가 markdown-link-check로 끊겼습니다.
README 등에 링크가 끊기면 새 멤버가 참여할 때 필요 없는 Q&A가 생기기 때문에 일단 해보는 게 좋을 것 같다.
사용 방법은 다음과 같다. 간단한 느낌.

$ yarn add -D markdown-link-check
$ markdown-link-check ./README.md

FILE: ./README.md
[✓] https://www.example.com
[✖] https://www.exampleeeeeeeeeee.com

Typo 검사

misspell-fixer를 사용하면 코드의 Typo를 검사할 수 있습니다.
Typo의 수정도 가능하며 명령줄의 사용 방법은 다음과 같다.

./misspell-fixer -frunRVD /path/to/src

옵션은 공식 홈페이지를 확인하세요.
상술한 예를 간단하게 설명하면 백업을 하지 않고 덮어쓰는 빠른 모드로 각종 희귀 규칙을 사용하는 느낌을 준다.
아무것도 검출되지 않으면 0으로 답장하고, 검출되면 0 이외의 것을 답장하기 때문에 CI에서 직접 실행하면 된다.
수정된 코드를 한 번 합쳐서 CI에서 Typo 검사를 하면 되잖아요.
참고로 우리 회사 코드 실시의 한 예는 이렇다.
Camel Case도 잘 대응하는 걸로 알고 있습니다.

유사한 도구인 파이톤제codespell도 있다.

사용된 패키지의 라이센스 확인

Copyleft 패키지를 사용하고 문제가 있으면 license-checker 설치된 패키지의 허가증을 검사할 수 있습니다.
일반적으로 간단한 설치와 운행만 하면 된다.

yarn add -D license-checker
license-checker

를 옵션html으로 하면 --production만 대상으로 한다.또한 CI에서 dependencies 또는 --onlyAllow를 사용하여 허가를 받거나 금지하고 싶은 허가증 목록을 제출하면 다른 허가증이 있는dependency가 있으면 오류가 발생할 수 있습니다.
하지만 모든 Copyleft를 지정할 수는 없습니다.

Access sibility 확인

나는 보조적인 검사를 위해 axe-core를 사용하는 곳이 매우 많다.
axe-storybook-testing를 사용하면 스토리북을 쉽게 확인할 수 있어 편리하다.
(겸사겸사 말씀드리지만, 이것은 장자크의 첫 번째 제품입니다. 이렇게 하는 것이군요.)
실행하면 성공과 실패가 표시됩니다.다음은 캡처의 일부분이지만 fail이 너무 많아요.

참고로 하려면 exe-coreDeque를 써야 할 것 같지만 현재 사용 경험이 없어서 아쉽습니다.

번들 크기 검사

bundlewatch를 사용하여 Webpack에 번들로 묶인 치수를 확인할 수 있습니다.
각각의 Chunk가 지정한 사이즈 이상이면 CI를 오류로 사용할 수 있습니다.
매번 CI로 밴드 링을 진행할 때마다 시간이 필요하기 때문에 --failOn 변경과 변경된 코드의 사이즈가 클 때만 하는 것이 좋습니다.
사이즈 내역을 좀 더 자세히 보려면 webpack-bundle-analyzer 사용할 수 있다.
보고서는 >이기 때문에 어디서 하숙을 하면 팀에서 공유하기도 쉽다.

danger-js에서 다양한 항목을 검사합니다

danger-js를 사용하면 페이지를 Issue에 링크할 수 있고 주석이 적당한 형식을 따를 수 있으며 페이지를 뒤집는 사이즈가 정해진 값을 초과할 수 있는지 등 여러 가지 검사를 할 수 있다.프로젝트에 맞추어 맞춤형으로 제작하는 것도 쉬워요. 공식 사이트에 편리한 예가 많으니까 꼭 보세요.

Static Code Analysis

eslint도 정적 코드 해석의 한 면이 있지만 보완적인 형식으로 다른 도구를 사용하는 경우도 많다고 생각합니다.
램프를 만들려면 지령선에서 간단히 semgrep할 수 있고, 만들려면 UI도 따라오는 것이 좋다SonarQube.
두 언어 모두 Type Script 이외의 언어에 해당합니다.package.json에서 규칙집을 찾을 수 있다여기. 등 다양한 것들이 있다.
역시 Early Access리액트용 규칙 세트도 좋을 것 같아요.
참고로 OWASP의 사이트에는 정적 코드 해석 도구의 목록이 있으니 참고하여 찾아보세요.

JetBrains의 Qodana.

모든 수법이 독특한 환경으로 설계되었다

프런트엔드 프로젝트https://owasp.org/www-community/Source_Code_Analysis_Tools 등을 사용하면 각 포맷의 독특한 URL을 통해 간단하게 프리뷰 버전으로 디자인할 수 있어 통합 전 동작 확인과 테스트가 수월하다.
모든 모델에 대해 백엔드 디자인을 하는 상황에서 실제 공식 환경과 같은 설정을 디자인했는데 관리 서비스는 개발 환경과 공통된 모델입니까?관리 서비스는 Netlify적인 것으로 일반적인 모델은 모든 모델을 컨테이너에 넣고 디버깅하는 것이라고 생각합니다.

문서 생성

디버그 미리보기가 있는 서비스를 제외하고 병합할 때만 CI보다 CD에 더 가까울 수 있음localstack 등 문서를 생성하고 어딘가에서 호스트를 진행하면 팀 간에 간단하게 공유할 수 있어 매우 편리하다.
typedoc에는 공식 시위 행진typedoc이 있다.
그리고 테스트 보고서 생성, 디버깅과 전방 프로젝트여기.의 생성과 디버깅도 같은 시간에 하는 것이 좋다.

최후

그래서 Type Script의 CI에서 하는 다양한 일들을 소개합니다.
수시로 업데이트할 예정입니다.이거 하는 게 좋을 것 같은 거 있으면 알려주세요.
Happy DevOpsing!