☰ Categories

Categories

Decide whether to add a dependency

Weighs writing it yourself against pulling a library, including the cost of removing it later.

CategoryDevelopment › Coding
TagsAnalyzingReviewingDeveloper
Prompt
Help me decide whether to add this dependency.

Work through:
1. What I actually need — the narrowest statement of it. Often much smaller than what the library does.
2. Rough size of writing it myself, for that narrow need only.
3. What the dependency brings beyond my need, and what that costs — bundle size, transitive dependencies, API surface I now must track.
4. Removal cost. How deeply would it spread through the codebase, and how hard would it be to take out in two years.
5. Failure modes — unmaintained, breaking changes, a security advisory I must respond to.
6. Whether the standard library or something already installed covers it.

Then: a recommendation with the condition that would flip it.

Rules:
- *Check step 6 before anything else.* Adding a dependency for something already available is the most common version of this mistake.
- For a need measured in a few dozen lines, the bar for a dependency should be high.
- *Do not assert facts about the library's maintenance status, size, or popularity* — I cannot verify what you recall. Say what to check instead.
After pasting, fill in the fields at the bottom (What I need · Candidate · Project context)

What this prompt does

Adding a dependency is easy and removing one is not. This weighs the time saved now against version pinning, security tracking, and eventual removal cost.

Model comparison

ChatGPT is the most precise and practical, covering validation and time-zone risks. Gemini reaches the right conclusion but is somewhat overconfident and verbose; [C] is missing.

ChatGPTTop overall
46/ 50

＋ Specifically covers validation, time zones, and SSR risks.

－ Checks step 6 first but later repeats it, muddling order.

Gemini
42/ 50

＋ Clearly prioritizes the existing date-fns dependency.

－ Overstates native ISO support and removal difficulty.

CriterionChatGPTGeminiLeader
Instruction following99Tie
Accuracy98ChatGPT +13%
Specificity109ChatGPT +11%
Structure99Tie
Right length97ChatGPT +29%

Scored 1–10 by gpt-5.6-sol with model names hidden (2026-09-24). This is an AI review, not a measurement.

Read full answers

We gave three models the same input and copied their answers unedited. Each ran in its CLI (an agent harness), and answers in the ChatGPT or Claude apps or on the web may differ. Outputs are in Korean.

Input used
What I need: 날짜 문자열을 여러 포맷(YYYY-MM-DD, MM/DD/YYYY, ISO 8601)으로 파싱하고 '3일 전' 같은 상대 시간으로 표시하는 기능

Candidate: dayjs

Project context: Next.js 14 기반 사내 어드민 대시보드(주문/정산 조회용), 팀 인원 2명. 일부 컴포넌트에서 이미 date-fns를 쓰고 있고, 번들 사이즈보다는 유지보수 부담을 줄이는 게 우선
gpt-5.6-luna (codex CLI · 에이전트 하네스) · Run on 2026-09-24

먼저 6번부터 보면, 이미 일부 컴포넌트에서 date-fns를 사용 중이므로 우선 기존 의존성으로 해결하는 것이 맞습니다. 표준 API도 상대 시간 표시에는 Intl.RelativeTimeFormat을 제공합니다.

  1. 필요한 기능의 최소 범위
  • YYYY-MM-DD, MM/DD/YYYY, ISO 8601 문자열을 날짜로 변환
  • 유효하지 않은 입력 처리
  • 현재 시각과 비교해 3일 전, 2시간 전처럼 표시
  • 필요하다면 표시 기준 시간대 명확히 지정

날짜 전체 기능이나 범용 날짜 객체 API가 필요한 것은 아닙니다.

  1. 직접 작성 규모

간단한 입력 규칙만 지원한다면 대략 수십 줄입니다.

  • 포맷별 정규식과 변환: 20~40줄
  • 윤년, 월/일 범위, 잘못된 날짜 검증: 10~20줄
  • 상대 시간 계산과 Intl.RelativeTimeFormat: 20~30줄

다만 ISO 8601의 시간대, 오프셋, 밀리초, DST까지 직접 다루기 시작하면 범위가 빠르게 커집니다.

  1. dayjs가 추가로 가져오는 것

dayjs는 다음과 같은 범용 기능을 제공합니다.

  • 날짜 포맷팅과 파싱
  • 상대 시간 플러그인
  • locale, UTC, timezone 등 확장 기능
  • 자체 API와 플러그인 사용 방식

현재 요구에는 이 중 일부만 필요합니다. 그 대가로 확인해야 할 것은 다음입니다.

  • 실제 프로덕션 번들 영향: Next.js 번들 분석기로 확인
  • 설치되는 직접·전이 의존성: package.json과 lockfile 확인
  • 팀이 추적해야 할 API와 플러그인 조합
  • date-fns와 dayjs가 함께 사용되면서 날짜 타입과 처리 방식이 이원화되는 비용

특히 이미 date-fns를 쓰고 있으므로 dayjs를 추가하면 라이브러리 선택지가 두 개가 됩니다.

  1. 제거 비용

도입 범위를 한 곳의 dateAdapter 또는 formatRelativeDate() 함수로 제한하면 제거 비용은 낮습니다. 반대로 컴포넌트 곳곳에서 dayjs()를 직접 호출하고 플러그인·locale에 의존하면 2년 후 제거 시 전체 검색과 단계적 치환이 필요합니다.

도입한다면 반드시 내부 래퍼 뒤에 숨기는 편이 안전합니다.

  1. 실패 가능성

확인할 항목은 다음입니다.

  • 저장소의 최근 릴리스, 이슈 대응, 지원 중인 버전
  • npm advisory와 GitHub security advisory
  • 새 버전에서의 breaking change와 플러그인 호환성
  • ISO 문자열의 시간대 처리 방식
  • 서버 렌더링과 브라우저 렌더링 간 상대 시간 결과 차이
  • YYYY-MM-DD를 UTC로 해석할지 로컬 날짜로 해석할지

라이브러리의 유지보수 상태나 보안 상태는 현재 확인 없이 단정하지 않는 것이 좋습니다.

  1. 기존 대안

현재 조건에서는 대안이 충분합니다.

  • 파싱과 날짜 계산: 이미 설치된 date-fns
    • parse, parseISO, isValid
    • formatDistanceToNow 또는 formatDistanceToNowStrict
  • 상대 시간: 표준 Intl.RelativeTimeFormat('ko', { numeric: 'auto' })
  • 단순 출력: Intl.DateTimeFormat

date-fns가 지원하지 않는 입력 형식만 작은 파서로 정규화한 뒤, 날짜 계산과 상대 시간 출력은 기존 도구에 맡길 수 있습니다.

추천

dayjs는 추가하지 않는 것을 권합니다. 이미 date-fns가 있고, 필요한 기능의 범위가 좁으며, 두 날짜 라이브러리를 함께 운영하는 유지보수 비용이 이득보다 커 보입니다.

권장 구조는 다음과 같습니다.

parseAdminDate(input: string): Date | null
formatRelativeAdminDate(date: Date): string

이 두 함수 안에서 입력 포맷과 상대 시간 정책을 통일하세요.

다음 조건이면 dayjs 도입을 재검토할 수 있습니다.

  • 여러 화면에서 timezone 변환, locale 전환, 복잡한 ISO 처리, 날짜 연산이 반복적으로 필요해지고
  • date-fns와 자체 유틸리티로 처리하는 코드가 라이브러리 도입보다 커지며
  • 실제 번들·lockfile·보안·유지보수 정보를 확인한 결과 팀이 수용할 만할 때

More in this category

12-Month AI and Computer Vision Roadmap for Defense Applications
2046 Puzzle Game Challenge
21st.dev component prompt
3D FACTORY
3D FPS Game