정규화된 이름 대 수입품의 정글

Contra에 원래 게시됨

Node.js 프로젝트와 해당 프로젝트 내에서 깊이 중첩된 파일을 열면 가장 먼저 다음과 같은 변형이 표시됩니다.

import { configureScope } from '@sentry/node';
import { serializeError } from 'serialize-error';
import { type CommonQueryMethods, sql } from 'slonik';
import { z } from 'zod';
import { Logger } from '../../Logger';
import { type CustomerIOService } from '../services';
import { type SendPlainEmailOptions } from '../types';
import { fetchUserSettings } from './fetchUserSettings';

애플리케이션 전체의 다양한 경로에서 가져온 수많은 가져오기를 볼 수 있습니다.
솔직히 우리가 왜 그렇게 하는지 모르겠다. 명시적이라는 것은 좋지만 가져오기 경로에 추가할 ../의 수와 일반적으로 모든 것이 어디에 있는지 기억해야 할 필요성을 알아내려고 할 때 끊임없는 추측 게임의 비용이 발생합니다.
TypeScript에서는 path mapping 을 사용하여 추측 게임을 줄일 수 있습니다. 일반적인 구성은 이제 절대 경로를 사용하여 모든 항목을 가져올 수 있는 "paths":{"@/*":["*"]}입니다. 이는 위의 코드를 다음과 같이 다시 작성하는 데 도움이 됩니다.

import { configureScope } from '@sentry/node';
import { serializeError } from 'serialize-error';
import { type CommonQueryMethods, sql } from 'slonik';
import { z } from 'zod';
import { Logger } from '@/Logger';
import { type CustomerIOService } from '@/customer/services';
import { type SendPlainEmailOptions } from '@/customer/types';
import { fetchUserSettings } from '@/customer/routines/fetchUserSettings';

코드를 보는 것만으로 무엇이 임포트되는지 알 수 있는 전체 컨텍스트가 있기 때문에 위의 내용이 이미 이해하기 더 쉽다고 주장합니다. 반면 상대 경로를 사용하면 상대 경로가 무엇을 해결하는지 계산하기 위해 정신 체조를 수행해야 합니다. 그러나 이 패턴은 여전히 ​​모든 것이 어디에 있는지 기억할 필요가 있습니다. 왜요? 무슨 소용이 있습니까? 아마도 더 좋은 방법이 있을 것입니다...

정규화된 이름 사용

단일 파일에서 모든 프로젝트 종속성을 가져올 수 있다면 더 쉽지 않을까요?

import {
  configureScope,
  serializeError,
  type CommonQueryMethods,
  sql,
  z,
  Logger,
  type CustomerIOService,
  type SendPlainEmailOptions,
  fetchUserSettings
} from '@/index';

이 접근 방식의 이점은 가져오기 위해 항목의 경로를 기억할 필요가 전혀 없다는 것입니다. 가져오려는 항목만 알면 됩니다. 이것은 또한 버그를 처리할 때 종속성과 원숭이 패치 종속성을 매우 쉽게 스텁할 수 있게 합니다.

단점은 공용 인터페이스가 있는 코드베이스의 모든 메서드와 변수가 고유한 이름(따라서 정규화된 이름)을 가져야 한다는 것입니다. 이것이 표준이 아님에도 불구하고 설명이 포함된 함수 이름을 선택해야 하고 선택하지 않을 때 코드 냄새를 알릴 수 있기 때문에 이것이 이점이라고 확실히 주장하고 싶습니다.

나는 우리가 이것을 하지 않을 타당한 이유를 알 수 없습니다.