This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
ongoing @peterhegman @svedova @pgascouvaillancourt @samdbeckham devops manage 2023-12-21

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 젬을 활용할 수 있습니다.
  • Nuxt 앱은 tailwindcss 모듈을 설정할 수 있습니다.
  • 더 일반적인 프론트엔드 스택은 tailwindcss 노드 모듈을 사용할 수 있습니다.

목표

이 블루프린트의 목표는 CSS 유틸리티 클래스를 다루는 경우 개발자 경험(DX)을 향상시키는 것입니다. 따라서 이 이니셔티브를 통해 프론트엔드 엔지니어의 효율성은 개발 오버헤드가 크게 감소하게 될 것입니다.

비목표

동기에서 언급했듯이, 이는 새로운 설계로 대체하는 것이 아닌 기존의 아키텍처 결정을 개선하는 데 중점을 두고 있습니다. 그러므로 이는:

  • _CSS 작성 방식이나 프로젝트 내에서 스타일을 적용하는 방식을 재방문하는 것_이 목적이 아닙니다.
  • 사용자 지향적인 개선에 중점을 두지 않습니다. 이 변경 사항은 주로 개발자 경험을 향상시키는 것입니다. 결과적으로 효율성의 증가는 사용자 경험을 간접적으로 향상시킬 수 있지만, 이것이 주된 의도는 아닙니다.

제안

우리는 GitLab UI와 GitLab에 Tailwind CSS를 설정할 것입니다. 목적은 GitLab UI에서 주요 Tailwind CSS 구성을 갖도록 하는 것입니다. 이 단계는 Pajamas 호환 구성 속성(색상, 간격 스케일 등)을 유지하고 있을 것입니다. GitLab에서는 GitLab 코드베이스와 @gitlab/ui 노드 모듈 모두를 스캔할 것입니다. 이는 GitLab UI가 더 이상 CSS 유틸리티를 노출할 필요가 없지만 GitLab에서는 여전히 이를 생성하고 있습니다. CSS 유틸리티를 사용하고 Tailwind CSS 기반 버전으로 업그레이드해야 하는 다른 프로젝트에도 유사한 설정이 도입되어야 합니다.

장점

  • 새로운 유틸리티를 추가하는 번거로운 작업을 제거할 것입니다. 다른 프로젝트에 기여하고 릴리스 주기를 통해 기다릴 필요 없이 즉시 어떤 유틸리티든 사용할 수 있어야 합니다.
  • 이름 정하는 것은 어려운 일이고, 잘 알려진 프로젝트로 이를 미루는 것이 가장 좋습니다. 따라서, 타일윈드 CSS 프로젝트에서 이름 정하도록 예측 가능한 라이브러리를 도입하게 될 것입니다.
  • 엔지니어는 이제 어떤 유틸리티가 사용 가능하며 그것을 어떻게 사용하는지를 알기 위해 Tailwind CSS 문서를 참고할 수 있어야 합니다. 더 이상 GitLab UI 소스 코드를 읽을 필요가 없을 것입니다.
  • Tailwind CSS가 소비자 코드베이스를 스캔하여 필요한 유틸리티를 생성하기 때문에 CSS 번들 크기를 유지 관리할 수 있을 것입니다. 그러나 이는 조금 주의해서 이해해야 합니다. Tailwind CSS는 매우 유연하며 때로는 개발자 정의 값으로 다양한 유틸리티를 생성할 수 있게 하므로, 기능에 따라 큰 유틸리티 번들이 생성되어 결과적으로 우리가 Tailwind CSS의 기능을 어떻게 채택하느냐에 따라 다를 수 있습니다.
  • 지원되는 유틸리티에 대해 자동 완성 및 미리보기를 제공하는 견고한 IDE 통합의 이점을 누릴 수 있을 것입니다.

단점

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

디자인 및 구현 세부 정보

깨지지 않도록 하기 위해 현재 라이브러리에서 벗어나는 반복적인 방법론을 채택하고 있습니다. 여기서 제시된 경로는 일부러 가공되지 않은 것입니다. 모든 상황에 적합한 해결책이 아니며, 중간에 몇몇 경우에 맞게 조정해야 할 수도 있다는 것을 인지하고 있습니다.

기본 과정은 다음과 같습니다:

  1. GitLab UI에서 유틸리티 믹스인 모음을 폐기합니다. 이것은 믹스인 이름에 gl- 접두사를 gl-deprecated-로 대체하고, GitLab UI와 GitLab의 모든 사용처를 업데이트하는 것을 의미합니다. 일반적으로 한 번에 한 믹스인 파일에 집중하지만, 작은 파일들이라면 여러 파일을 한꺼번에 폐기하고 여러 번에 걸쳐 진행해야 할 수도 있습니다.
  2. 해당 Tailwind CSS 핵심 플러그인들을 활성화하여 새로운 유틸리티를 즉시 사용할 수 있도록 합니다.
  3. 폐기된 유틸리티를 해당 Tailwind CSS와 동등한 것으로 이관합니다.
flowchart TD RequiresDeprecation(GitLab에서 믹스인 모음을 널리 사용하나요?) DeprecateMixins[불평을 표시하여 `gl-deprecated-` 접두사를 믹스인에 추가] HasTailwindEq(Tailwind CSS에 해당하는 항목이 있나요?) EnableCorePlugin["해당하는 Tailwind CSS 핵심 플러그인(s) 활성화"] WriteCustomUtil[사용자 정의 Tailwind CSS 유틸리티 작성] MigrateUtils[레거시 유틸리티를 Tailwind CSS로 이관] RequiresDeprecation -- Yes --> DeprecateMixins DeprecateMixins --> HasTailwindEq RequiresDeprecation -- No --> HasTailwindEq HasTailwindEq -- Yes --> EnableCorePlugin HasTailwindEq -- No --> WriteCustomUtil EnableCorePlugin --> MigrateUtils WriteCustomUtil --> MigrateUtils

폐기 단계는 프로덕션 과정에서 각각의 이전에 대하여 평가할 여지를 제공해줍니다. 그러나 이 방법에는 일부 단점이 있습니다:

  • 다른 사람들에게 Merge 충돌을 발생시킬 수 있으므로 우리의 폐기 MR에서 제품의 여러 영역을 건드리게 될 것입니다. 혼란스럽지 않도록 효율적인 방법으로 이러한 변경 사항을 전달하기 위해 노력할 것입니다. 또한 범위가 너무 크다고 판단되는 경우 MR을 분할하는 것이 가장 좋은 판단이 될 것입니다.
  • 폐기 MR에는 여러 부서의 승인이 필요할 수 있으므로 이와 같은 이유로 프로세스 전반에 걸쳐 투명하고 반복적으로 진행할 필요가 있습니다.
  • 우리는 일부러 기술적 부채를 도입하고 있으며, 합리적인 시간 내에 상환할 것을 약속하고 있습니다. 실제로 이 단계가 소요되는 기간은 여러 요소(특이한 경우 발견, DRI의 용량, 부서 전반적인 참여 등)에 따라 영향을 받을 수 있지만, 6-12개월 내에 완료될 것으로 예상하고 있습니다.