• 요약
• 동기
  • 왜 Tailwind CSS인가요?
  • 목표
  • 비목표
• 제안
  • 장점
  • 단점
• 디자인 및 구현 세부 정보

Tailwind CSS로 CSS 유틸리티 클래스 생성 위임

요약

GitLab에서 요소를 스타일링하는 데에는 주로 CSS 유틸리티 클래스가 사용됩니다. 일반적으로 하나의 CSS 속성을 정의하고 요소의 모양을 변경하기 위해 추가적으로 적용할 수 있는 클래스입니다. 필요한 유틸리티를 생성하기 위해 GitLab UI 프로젝트에서 자체 도구를 개발했지만, 이 접근 방식에는 여러 결함이 있음을 보여주므로 이 작업을 Tailwind CSS 프레임워크에 위임하는 것이 바람직합니다.

이 계획에는 기존의 유틸리티를 폐기하고 그 자리에 Tailwind CSS를 도입해야 합니다.

동기

2019년 6월, RFC#4를 통해 CSS 유틸리티 클래스의 사용을 합리화했으며, 이는 수동으로 정의된 SCSS 믹스인 모음에서 유틸리티를 생성하는 ‘silent 클래스’의 개념을 도입했습니다.

이로써 잘 사용되었지만 몇 가지 주요 단점이 있었습니다:

• 증가한 개발 부담: 필요한 새 유틸리티를 수동으로 GitLab UI 프로젝트에 추가해야 합니다. 그런 다음 @gitlab/ui의 새 버전이 출시되고 소비자 프로젝트에 설치되기를 기다려야 합니다.
• 일관성 부족: 유틸리티 이름을 검사할 도구가 없어 라이브러리에 많은 일관성 부족이 있었으며, 가장 두드러진 예로는 대다수의 모바일 우선 유틸리티들 사이에 데스크톱 우선 유틸리티가 도입되었지만 소스를 살펴봐야만 그 전후를 구분할 방법이 없었습니다.
• 유틸리티 라이브러리와 그 사용자 간의 연결이 끊김: 유틸리티가 라이브러리에 추가되면 @gitlab/ui를 사용하는 모든 프로젝트에서 사용할 수 있게 됩니다. 결과적으로 어떤 프로젝트가 그것들을 필요로 하지 않으면 일부 유틸리티가 프로젝트에 포함됩니다. 반대로 모든 사용자가 특정 유틸리티를 사용 중지하면 CSS 번들 크기를 줄이기 위해 해당 유틸리티를 제거할 수 있지만 우리는 이에 대해 시각적으로 확인할 방법이 없습니다.
• 자동완성 제한: 기존 라이브러리에 대한 자동완성 구성은 가능하지만 그것은 유틸리티 번들에 제한됩니다. 반면, Tailwind CSS의 자동완성은 온디맨드 방식과 일치하여 모든 유틸리티가 즉시 사용 가능하도록 보장합니다. 또한 IDE 확장 프로그램은 특정 유틸리티가 적용된 값을 노출하여 이해를 향상시킬 수 있습니다.

이 아키텍처 변경의 일환으로, CSS 유틸리티를 생성하기 위한 자체 솔루션을 폐기하고 이 작업을 Tailwind CSS에 위임하여 이러한 문제들을 완화할 예정입니다.

이전에 RFC#107에서 이에 대해 논의되었음을 언급해야 합니다. 이 RFC는 호응을 얻었으며 제기된 몇 가지 우려사항은 우리가 어떻게 이를 구현했는지가 아니라 CSS 유틸리티 접근 자체에 대해 였습니다. 이 계획의 목적은 유틸리티 클래스에 대한 의존성을 의문 할 것이 아니라, CSS 유틸리티와 작업할 때 엔지니어의 효율성을 개선하는 데 있습니다.

왜 Tailwind CSS인가요?

유사한 도구들 대신 Tailwind CSS를 선택한 몇 가지 이유는 다음과 같습니다:

• 많은 프로덕션 앱에서 테스트된 오랜 기간의 프로젝트입니다. 건강한 커뮤니티가 그 주위에서 활발히 활동하고 있습니다.
• Tailwind CSS는 잘 유지 보수되고 불필요하게 부풀려지지 않고 계속 발전하고 있습니다.
• Ruby on Rails 프로젝트는 tailwindcss-rails Gem를 활용할 수 있습니다.
• Nuxt 앱은 tailwindcss 모듈을 설정할 수 있습니다.
• 보다 일반적인 프론트엔드 스택은 tailwindcss Node 모듈을 사용할 수 있습니다.

목표

이 청사진의 목표는 CSS 유틸리티 클래스로 작업할 때 개발자 경험(DX)을 개선하는 것입니다. 이 계획의 결과로 프론트엔드 엔지니어들의 효율성은 개발 부담이 크게 줄어듦으로써 향상될 것으로 기대합니다.

비목표

위에서 말한 동기들에 따라, 이는 기존 아키텍처 결정을 개선하는 데 집중되어 있으며 새로운 디자인으로 대체하려는 것은 아닙니다. 따라서 이 청사진은 다음과 같습니다:

• CSS 작성이나 프로젝트 내에서 스타일을 적용하는 방식을 재검토할 목적은 아닙니다.
• 사용자 개선에 초점을 맞추지 않습니다. 이 변경은 주로 개발자 경험을 향상시키는 것입니다. 결과적으로 효율성 향상은 사용자 경험을 간접적으로 향상시킬 수 있지만, 이가 우리의 주요 목적은 아닙니다.

제안

GitLab UI 및 GitLab에 Tailwind CSS를 설정할 것입니다. 이러한 계획은 GitLab UI에 Tailwind CSS 구성을 유지하는 것입니다. 여기에서는 Pajamas에 준하는 구성 속성(색상, 간격 스케일 등)을 유지할 것입니다. GitLab에서는 GitLab 코드베이스와 @gitlab/ui 노드 모듈을 모두 스캔할 것입니다. 이로써 GitLab UI는 더 이상 CSS 유틸리티를 노출할 필요가 없지만, 그가 의존하는 것들은 GitLab에서 생성되는 것입니다. CSS 유틸리티를 사용하고 Tailwind CSS 기반 버전으로 업그레이드해야 하는 다른 프로젝트에도 유사한 설정을 도입해야 할 것입니다.

장점

• 새 유틸리티를 추가하는 번거로운 작업 흐름을 제거했습니다. 이제는 다른 프로젝트에 기여하고 릴리스 주기를 기다릴 필요 없이 즉시 유틸리티를 사용할 수 있어야 합니다.
• 우리는 예측 가능한 라이브러리를 소개하고, 여기서 이름은 종합적인 Tailwind CSS 프로젝트에서 결정됩니다. 엔지니어들은 이름 짓기가 어렵다는 것을 아는데, 이것을 잘 정립된 프로젝트로 미루는 것이 가장 좋습니다.
• 엔지니어들은 이제 GitLab UI의 소스 코드를 읽을 필요없이 Tailwind CSS 문서를 참조하여 사용 가능한 유틸리티와 사용 방법을 파악할 수 있어야 합니다.
• Tailwind CSS는 소비자의 코드베이스를 스캔하여 필요한 유틸리티를 생성하기 때문에, 실제로 필요한 유틸리티만 생성하여 CSS 번들 크기를 컨트롤할 수 있을 것입니다. 이는 주의가 필요한 부분이지만, Tailwind CSS는 매우 유연하여 개발자가 정의한 값과 함께 종종 다양한 유틸리티를 생성할 수 있어서, Tailwind CSS의 기능을 어떻게 채택하느냐에 따라 대형 유틸리티 번들이 생성될 수 있습니다.
• 우리는 지원하는 유틸리티에 대한 자동 완성과 미리보기를 제공하는 견고한 IDE 통합에서 혜택을 얻을 것입니다.

단점

• 더 많은 설정: CSS 유틸리티가 필요한 각 프로젝트마다 Tailwind CSS를 설정해야 하므로, 환경에 따라 더 쉬울 수도, 더 까다로울 수도 있습니다.
• 각 프로젝트에 하나의 더 많은 개발 의존성.
• 동적으로 클래스 이름을 구축하기 위해 문자열 보간을 사용할 수 없음(Tailwind CSS는 필요한 클래스를 생성하기 위해 전체 이름을 보여주어야 함).
• 마이그레이션을 해야 합니다: 현재의 CSS 유틸리티 라이브러리의 사용을 중단시키기 위해 기존의 사용 방법이 깨지지 않도록 보장해야 하며, 이는 폐기/마이그레이션 프로세스를 의미합니다.

디자인 및 구현 세부 정보

손상을 방지하기 위해 우리는 현재 라이브러리에서 벗어나기 위해 반복적인 접근 방식을 채택하고 있습니다. 여기에 제안된 경로는 일부러 가공되어 여러 측면에서 적용하기 어려운 해결책이라고 인정합니다. 우리는 일부 케이스에 맞춰 조정해야 할 수도 있고, 일부 케이스에 한해 일괄적으로 적용할 수 있는 해결책은 아니다.

기본적인 절차는 다음과 같습니다:

1. GitLab UI에서 일련의 유틸리티 믹스인을 폐기(A collection of utility mixins in GitLab)합니다. 이것은 믹스인의 이름에서 gl- 접두어를 gl-deprecated-로 대체하고, GitLab UI와 GitLab 모두의 모든 사용 사례를 업데이트하는 것을 의미합니다. 일반적으로 한 번에 한 믹스인 파일에 집중하지만, 작은 파일의 경우 여러 파일을 한꺼번에 폐기하고 싶을 수도 있습니다. 반면에 어떤 파일은 한 번에 폐기하기에는 너무 크거나 여러 번의 반복이 필요할 수 있습니다.
2. 해당 Tailwind CSS core plugins를 활성화하여 새로운 유틸리티를 즉시 사용할 수 있게 합니다.
3. 폐기된 유틸리티들을 그들의 Tailwind CSS 상당품과 동등하게 이전합니다.

폐기 단계에서는 우리에게 생산적인 휴는 제공하지만, 몇 가지 단점이 있습니다:

• 다른 사용자들에게 병합 충돌을 일으킬 수도 있으며, 우리의 폐기 Merge Request(MR)에서 제품의 여러 영역을 수정할 것이므로, 이러한 변경 사항을 혼란스럽게 만들지 않도록 효율적으로 이러한 변경 사항을 전파하기 위해 노력할 것입니다. 또한, 범위가 너무 클 경우 MR을 분할하는 판단에 우리의 최선을 다할 것입니다.
• 폐기 MR에는 몇몇 부서의 승인이 필요할 수 있으며, 이는 프로세스 중에 투명하고 반복적으로 진행되어야 하는 이유입니다.
• 우리는 일정 기간 내에 상당한 기술적 부채를 도입했지만, 합리적인 시간 내에 지불할 것을 약속합니다. 이 프로젝트의 실제 기간이 여러 가지 요인(특이 사례 발견, 책임을 지고 있는 역할(DRIs)의 용량, 부서 전체의 참여 등)에 의해 영향을 받을 수 있다는 것을 인정하지만, 우리는 6-12개월 내에 완료될 것으로 기대합니다.