기존 JS 보안에 대해 Pretter를 동일하게 적용한다면

생동감 넘치는 정원 Advent Calendar 2021 다음 날이다.
안녕하세요, 초콜릿 개발을 도와드립니다@ogawa65a.
커지기 시작한 코드 기반의 리더십을 개선하기 위해 코드 연출자를 가져올 생각은 없으신가요?
그러나 기존의 코드 기초에 대해 자동 포맷 수정을 통일적으로 적용하는 것은 불안하지 않겠는가?
그렇다고 변경 내용을 모두 눈으로 확인하는 것도 어렵다.
따라서 초콜릿을 먹을 때 기존 JS에 Preettier를 안전하고 효과적으로 적용하는 방법을 소개한다.
Pretter
설정할 수 있는 옵션이 매우 적은 것이 특징인 코드 포맷기다.
Proettier의 디자인 사상은'코딩 스타일에 대한 모든 토론을 멈추자'는 것이다.
더 많은 옵션이 있다면 어떤 옵션을 유효하게 설정할지 토론하기 시작할 것이다. 이것은 본말이 뒤바뀐 생각이다.
많은 프로그래밍 언어가 지원되지만 이번에는 JS를 대상으로 설명하려고 한다.
Pretier 도입 후 과제
올해는 팀 엔지니어 수가 급격히 늘어나면서 초콜릿을 먹는 데 코드 포맷이 통일되지 않는 문제에 직면해 프리티어를 도입했다.
당초 Prettier를 가져올 때는 기존 코드에 Prettier를 적용하지 않고 확장 가능한 라이브러리에 새로 추가되거나 변경된 파일에만 GiitHub Actions를 사용하여 Prettier를 검사합니다.
그러나 기존 파일의 일부만 수정됐을 뿐 다른 많은 곳에 프리티어의 자동 수정이 적용됐고, 리블릭의 차이가 프리티어의 수정인 경우가 많아 코드 검토가 어려운 상태였다.
Prettier의 수정 제출을 분리해 리뷰를 진행하면 문제가 다소 줄어들 수 있지만, 리뷰에 적시된 사항의 수정 제출이 다시 쌓이면 Prettier의 제출이 다른 제출에 끼어 리뷰를 하기 어려운 문제가 있다.
어쨌든 프리티어의 수정이 장애가 될 수 있는 상황에서prettierignore에 추가돼 검사 대상에서 잠시 제외되는 경우도 있지만 이러면 전혀 전진할 수 없습니다.
따라서 기존 코드의 프리티어 적용에도 꾸준하지 않다면... 이렇게 생각하면서 문제를 효과적으로 해결할 수 있을지 모색하고 있다.
우선 코드 기초 전체에 적용해 봅시다
어쨌든 무슨 일이 일어날지 먼저 시험해 보고 코드를 바탕으로 프리티어를 적용해 봤다.

이렇게 되면 무섭지는 않지만 너무 무서워서 합병도 논평도 할 수 없다.
아니면 너무 무거워서 File changed를 열 라벨도 없다.
자세히 보면 실제로 수정된 내용은 다음과 같다.

줄 바꿈 위치 수정

꼬리 쉼표 추가

{} 내부 공간 추가

기본적으로 모두 공식적인 트위터라는 것은 당연한 일이지만, 나는 거의 모든 수정이 문법에 해당한다는 것을 발견했다.
그렇다면 웹 팩으로 JS를 구축하면 결국 같은 번들 방식이 될 수 있지 않을까요?이런 예견이 있었다.
Pretier 어플리케이션 전후에 달러가 일치하는지 확인해 보십시오.
Prettier를 적용하기 전후에 각각 프로덕션으로 구축된 묶음이 같다면 최종적으로 묶음이 나눠지기 때문에 Proettier를 안심하고 사용할 수 있다.
아래와 같이 여러 개의 묶음을 할 수 있는데 파일 이름은 [name]-[contenthash].js이다.

$ webpack build --node-env=production
$ ls public/entries
app1-578d7f8fbcd7d5a41f90.js
app2-b9a19f69d7d0c0e12917.js
...

Priettier 적용 전public/을 public_before/로 회피하고, Priettier 적용 후public/를 public_after/로 이름을 바꿉니다.
다음에, 우리는 묶음이 일치하는지 확인하기 위해 스크립트를 준비할 것이다.
이번에는 루비가 각본을 썼다.
파일 이름[contenthash]이 일치하면(즉, 파일 이름이 일치하면) 번들의 내용도 같다.

before_bundles = Dir.glob("**/*.js", base: "public_before/entries").sort
after_bundles = Dir.glob("**/*.js", base: "public_after/entries").sort

same_bundles = before_bundles & after_bundles
puts same_bundles
puts same_bundles.length

different_bundles = before_bundles - same_bundles
puts different_bundles
puts different_bundles.length

이 스크립트를 실행한 결과 약 100개의 묶음 중 95개의 묶음이 있었다.
따라서 일관된 번들 소스 코드에 대해 Preettier를 사용할 수 있습니다.
묶음이 바뀐 소스 코드를 확인해 보세요.
여기까지만 해도 일치하지 않는 묶음 소스 코드는 그대로 두고 나중에 눈으로 평론해도 문제없지만 가까스로 더 깊이 파고들었다.
보통 여러 개의 원본 코드가 한 파일에 묶여 있습니다.
따라서 바뀐 묶음은 5개지만 대응하는 소스 코드는 5개 이상이다.
그 중 모든 소스 코드의 Prettier 수정은 묶음을 바꾸는 원인이 되지 않을 것입니다.
그래서 묶은 원본 코드를 바꿨는지 확인하고 싶습니다.
실제로 우리는 달러의 구체적인 변화를 확인할 것이다.
여기서 프리티어에 직접 적용한 전후 묶음을 diff하면 묶음 달러가 최소화돼 한 줄로 바뀌어 어디에 변화가 생겼는지 알 수 없다.
따라서 달러에 Priettier를 한 번 적용한 후 diff를 받습니다.

$ prettier --write public_before/entries/app1-578d7f8fbcd7d5a41f90.js
$ prettier --write public_after/entries/app1-28b709482ec2bd6e901a.js
$ diff public_before/entries/app1-578d7f8fbcd7d5a41f90.js public_after/entries/app1-28b709482ec2bd6e901a.js

이렇게 하면 차분의 원인이 나타난다.
그 차이는 어느 소스 코드에서 왔는지grep가 확인하면 많은 경우에 바로 알 수 있다.
참고로 이번에 우리는 다음과 같은 React의 원본 코드인 Pleettier의 수정이 묶음의 차이를 발견했다.

  <span>
-   あいうえお{" "}
-   かきくけこ
---
+   あいうえお かきくけこ
  </span>

위에서 말한 바와 같이 텍스트에서 줄을 바꿀 때 JSX로 공백을 명확하게 삽입하고 한 줄로 합친 후 공백 부분을 원시 텍스트로 삽입한다.
이렇게 하면 구체적인 소스 코드의 수정 위치를 지정함으로써 소스 코드 이외의 응용 프로그램인 프리티어도 문제가 없다는 것을 확인할 수 있다.
이번에 바뀐 5개의 묶음 결과 총 5개의 원본 코드가 원인에 따라 달라진 것으로 나타났다.
처음에 724의 파일이 변경되었는데, 그 결과 이 5개를 제외하고 719의 원본 코드는 프리티어를 통일적으로 사용해도 변하지 않는 것으로 나타났다.
나머지 5개의 파일은 다른 페이지에 Prettier를 적용하여 눈 검사를 했습니다. 이렇게 하면 기존 JS에 Prettier를 안전하게 적용할 수 있습니다!
최후
더듬으며 속수무책으로 시작해 만족스러웠다.
여기에 설명된 방법은 JS 이외의 코드나 Priettier 이외의 도구에도 적용될 수 있습니다. 예를 들어sed로 한꺼번에 교체하는 경우 등입니다.
먹다 남은 음식을 먹는 코드베이스에는 프런트와 서버 측의 과제가 많아 시행착오와 착실한 개선이 이어지길 기대한다.
관심이 있다면 초콜릿을 꼭 보러 가세요!
겸사겸사 제품팀 어때요?