Closed sungik-choi closed 1 year ago
Latest commit: 00661bef6eb6c26d386ffb197134a3976cf50fb6
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
Patch coverage: 95.72
% and project coverage change: +0.07
:tada:
Comparison is base (
2476407
) 77.93% compared to head (00661be
) 78.00%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
About Prettier 관련
한가지 예로 ESLint에서는 non-js 파일에 대한 포매팅이 되지 않는 것으로 알고 있는데, prettier를 통해서 이를 해결할 수 있는 케이스는 있을거 같습니다. 오늘 아침에 제가 Contributing.md를 고쳤을때의 예시가 있겠네요.
저는 Prettier를 도입하지 않더라도, printWidth를 대체하는 Lint Rule 정도는 팀원들끼리 컨벤션을 정하면 좋을거 같다고 생각합니다!
현재 저희 Lint로는 위의 구조에서 일관적인 포맷팅이 안되는데, Prettier에서는 자동으로 맞춰주는 차이도 있겠네요!
About Prettier 관련
- ESLint와 Prettier는 서로 양립할 수 있는 포맷터입니다. 꼭 Prettier를 쓴다고 해서 Eslint의 포맷팅을 포기해야하는 것은 아닙니다!
- 이 점에 대해서는 동의합니다! Prettier의 로직을 적용할만한 로직이 있을떄 추가하는 것 정도도 적당할 것 같습니다. 꼭 필요하지 않다면 불필요한 복잡성이 하나 추가되는 것과 동일하기에... 혹시 Prettier를 처음 도입하기로 생각하셨던 동기가 있으면, 그것이 ESLint만으로 해결될수 있는 문제인지에 대해서 한번 확인해보면 좋을거 같습니다!
한가지 예로 ESLint에서는 non-js 파일에 대한 포매팅이 되지 않는 것으로 알고 있는데, prettier를 통해서 이를 해결할 수 있는 케이스는 있을거 같습니다. 오늘 아침에 제가 Contributing.md를 고쳤을때의 예시가 있겠네요.
저는 Prettier를 도입하지 않더라도, printWidth를 대체하는 Lint Rule 정도는 팀원들끼리 컨벤션을 정하면 좋을거 같다고 생각합니다!
@channel.io/eslint-config
)과 충돌이 발생합니다. eslint-config-prettier
도 ESLint의 규칙을 끄는 방식으로 동작하구요. 양립하게하려면 저희 ESLint 포매팅 관련 설정을 Prettier의 설정에 맞게 마이그레이션해야 하는데, 좋은 방식인지는 의문이 듭니다. 팀의 ESLint 설정을 바꾸고 팀 전체에 Prettier를 적용하는게 아니면 어려울 거 같다는 생각이에요.editorconfig
를 사용하고 있어서 이 부분도 논의를 해봐야합니다.저도 prettier를 도입하려면, bezier뿐만 아니라 채널코퍼레이션의 모든 코드에 마이그레이션해야하는 거대한 작업이 될 수 있다는 것에 동의하고, 이 PR에서 해결될 필요는 없다고 생각합니다. 그러나 개인적으로는 차후에라도 도입하는게 좋다고 생각합니다. Eslint의 경우에는 한줄 개행의 포매팅을 전혀 해주지 못해, PR 올릴떄의 불필요한 Diff가 생기는 것을 막지 못합니다. 또한 한줄 개행/그렇지 않음으로 인한 일관성이 깨지는 문제가 존재합니다.
<div>
고양이
</div>
<div>
고양이
</div>
<div>
고양이
</div>
<div>
고양이
</div>
위 4개의 달라지는 코드 스타일을 ESLint상에서 자동으로 잡지 못하기 때문입니다.
Self Checklist
CODEOWNERS
file.Related Issue
Fixes #1210
Summary
ESLint 규칙을 개선하고, 코드 전반을 포매팅합니다.
Details
New Rule
아래 규칙을 적용하고자 했습니다.
type
키워드가 가능한 경우 일관적으로 추가하도록 통일합니다.또한
@channel.io/eslint-config
에서 불필요하게 비활성화하고 있던 a11y 관련 규칙을warn
level로 활성화합니다.우선은
warn
level로 유지하는 방향을 선택했습니다. 추후 error level로 변경하고 개선해야합니다.About Prettier
Prettier는 다음과 같은 이유로 적용하지 않았습니다.
@channel.io/eslint-config
)은 코드 포매터의 역할도 겸하고 있습니다. hook deps의 개행 규칙처럼 Prettier가 하는 역할보다 훨씬 다양한 역할을 수행하고 있어서,eslint-config-prettier
를 적용해서 Prettier와 충돌하는 ESLint 규칙을 비활성화하더라도, 기존 ESLint가 하던 역할을 Prettier가 온전히 대체할 수 없습니다. bezier-react는 오픈소스이지만, 채널 웹팀이 주로 관리하고 있는 프로젝트이기에 채널 웹팀의 코드 컨벤션에 맞추는 편이 개발자 경험에 훨씬 나은 방향이라고 판단했습니다.printWidth
,arrowParens
같은 규칙은 이미 팀의 컨벤션으로 따로 정해져 있지 않은 상태(rule off)이기에 굳이 강제할 필요가 없다고 판단했습니다. (정하더라도 ESLint의 규칙으로 설정하면 충분하다고 판단했습니다)이미 pre-commit 훅에 lint 과정이 포함되어있고(lint-staged), 에디터에 format on auto-save 기능이 있으므로 pre-commit에 auto fix 커맨드를 추가하진 않았습니다.
etc
Breaking change or not (Yes/No)
No
References
verbatimModuleSyntax
옵션을 적용한다면 살펴보아야 함. (#)