기본 방식으로 프런트엔드 프로젝트에서 경로 별칭을 구성하는 방법

경로 별칭 정보

프로젝트는 복잡하고 중첩된 디렉터리 구조로 발전하는 경우가 많습니다. 결과적으로 가져오기 경로가 길어지고 더 혼란스러워질 수 있으며, 이는 코드의 모양에 부정적인 영향을 미치고 가져온 코드의 출처를 이해하기 더 어렵게 만들 수 있습니다.

경로 별칭을 사용하면 미리 정의된 디렉터리에 상대적인 가져오기 정의를 허용하여 문제를 해결할 수 있습니다. 이 접근 방식은 가져오기 경로 이해와 관련된 문제를 해결할 뿐만 아니라 리팩토링 중 코드 이동 프로세스도 단순화합니다.

 // Without Aliases import { apiClient } from '../../../../shared/api'; import { ProductView } from '../../../../entities/product/components/ProductView'; import { addProductToCart } from '../../../add-to-cart/actions'; // With Aliases import { apiClient } from '#shared/api'; import { ProductView } from '#entities/product/components/ProductView'; import { addProductToCart } from '#features/add-to-cart/actions';

alias-hq 및 tsconfig-paths 와 같이 Node.js에서 경로 별칭을 구성하는 데 사용할 수 있는 여러 라이브러리가 있습니다. 그러나 Node.js 문서를 살펴보면서 타사 라이브러리에 의존하지 않고도 경로 별칭을 구성하는 방법을 발견했습니다.

또한 이 접근 방식을 사용하면 빌드 단계 없이 별칭을 사용할 수 있습니다.

이 글에서는 Node.js 하위 경로 가져오기 와 이를 사용하여 경로 별칭을 구성하는 방법에 대해 설명합니다. 또한 프론트엔드 생태계에서의 지원도 살펴보겠습니다.

수입 분야

Node.js v12.19.0부터 개발자는 하위 경로 가져오기를 사용하여 npm 패키지 내에서 경로 별칭을 선언할 수 있습니다. package.json 파일의 imports 필드를 통해 이 작업을 수행할 수 있습니다. npm에 패키지를 게시할 필요는 없습니다.

임의의 디렉터리에 package.json 파일을 생성하면 충분합니다. 따라서 이 방법은 개인 프로젝트에도 적합합니다.

경로 별칭에 대한 기본 지원은 이론적으로 다음과 같은 장점이 있습니다.

• 타사 라이브러리를 설치할 필요가 없습니다.

• 코드를 실행하기 위해 즉시 가져오기를 사전 빌드하거나 처리할 필요가 없습니다.

• 별칭은 표준 가져오기 확인 메커니즘을 사용하는 모든 Node.js 기반 도구에서 지원됩니다.

• 코드 탐색 및 자동 완성은 추가 설정 없이 코드 편집기에서 작동해야 합니다.

내 프로젝트에서 경로 별칭을 구성하려고 시도하고 실제로 해당 명령문을 테스트했습니다.

경로 별칭 구성

예를 들어, 다음과 같은 디렉터리 구조를 가진 프로젝트를 고려해 보겠습니다.

 my-awesome-project ├── src/ │ ├── entities/ │ │ └── product/ │ │ └── components/ │ │ └── ProductView.js │ ├── features/ │ │ └── add-to-cart/ │ │ └── actions/ │ │ └── index.js │ └── shared/ │ └── api/ │ └── index.js └── package.json

경로 별칭을 구성하려면 설명서에 설명된 대로 package.json 에 몇 줄을 추가하면 됩니다. 예를 들어, src 디렉터리를 기준으로 가져오기를 허용하려면 package.json 에 다음 imports 필드를 추가하세요.

 { "name": "my-awesome-project", "imports": { "#*": "./src/*" } }

구성된 별칭을 사용하려면 다음과 같이 가져오기를 작성할 수 있습니다.

 import { apiClient } from '#shared/api'; import { ProductView } from '#entities/product/components/ProductView'; import { addProductToCart } from '#features/add-to-cart/actions';

설정 단계부터 첫 번째 제한 사항에 직면합니다. imports 필드의 항목은 # 기호로 시작해야 합니다. 이렇게 하면 @ 같은 패키지 지정자와 구별됩니다.

이 제한은 개발자가 가져오기에서 경로 별칭이 사용되는 시기와 별칭 구성을 찾을 수 있는 위치를 신속하게 결정할 수 있기 때문에 유용하다고 생각합니다.

일반적으로 사용되는 모듈에 대해 더 많은 경로 별칭을 추가하려면 imports 필드를 다음과 같이 수정할 수 있습니다.

 { "name": "my-awesome-project", "imports": { "#modules/*": "./path/to/modules/*", "#logger": "./src/shared/lib/logger.js", "#*": "./src/*" } }

"다른 모든 것은 즉시 사용할 수 있습니다."라는 문구로 기사를 마무리하는 것이 이상적입니다. 그러나 현실적으로 imports 분야를 활용하려고 한다면 몇 가지 어려움에 직면할 수 있습니다.

Node.js의 한계

CommonJS 모듈 과 함께 경로 별칭을 사용할 계획이라면 나쁜 소식이 있습니다. 다음 코드는 작동하지 않습니다.

 const { apiClient } = require('#shared/api'); const { ProductView } = require('#entities/product/components/ProductView'); const { addProductToCart } = require('#features/add-to-cart/actions');

Node.js에서 경로 별칭을 사용할 때는 ESM 세계의 모듈 확인 규칙을 따라야 합니다. 이는 ES 모듈과 CommonJS 모듈 모두에 적용되며 충족되어야 하는 두 가지 새로운 요구 사항이 발생합니다.

1. 파일 확장자를 포함하여 파일의 전체 경로를 지정해야 합니다.

   
   

2. 디렉터리 경로를 지정하고 index.js 파일을 가져올 것으로 예상하는 것은 허용되지 않습니다. 대신 index.js 파일의 전체 경로를 지정해야 합니다.

Node.js가 모듈을 올바르게 해석할 수 있도록 하려면 가져오기를 다음과 같이 수정해야 합니다.

 const { apiClient } = require('#shared/api/index.js'); const { ProductView } = require('#entities/product/components/ProductView.js'); const { addProductToCart } = require('#features/add-to-cart/actions/index.js');

이러한 제한으로 인해 CommonJS 모듈이 많은 프로젝트에서 imports 필드를 구성할 때 문제가 발생할 수 있습니다. 그러나 이미 ES 모듈을 사용하고 있다면 코드가 모든 요구 사항을 충족하는 것입니다.

또한 번들러를 사용하여 코드를 빌드하는 경우 이러한 제한을 우회할 수 있습니다. 아래에서 이를 수행하는 방법에 대해 논의하겠습니다.

TypeScript에서 하위 경로 가져오기 지원

유형 검사를 위해 가져온 모듈을 올바르게 확인하려면 TypeScript가 imports 필드를 지원해야 합니다. 이 기능은 버전 4.8.1부터 지원 되지만 위에 나열된 Node.js 제한 사항이 충족되는 경우에만 지원됩니다.

모듈 확인을 위해 imports 필드를 사용하려면 tsconfig.json 파일에서 몇 가지 옵션을 구성해야 합니다.

 { "compilerOptions": { /* Specify what module code is generated. */ "module": "esnext", /* Specify how TypeScript looks up a file from a given module specifier. */ "moduleResolution": "nodenext" } }

이 구성을 사용하면 imports 필드가 Node.js에서와 동일한 방식으로 작동할 수 있습니다. 즉, 모듈 가져오기에 파일 확장자를 포함하는 것을 잊어버린 경우 TypeScript는 이에 대해 경고하는 오류를 생성합니다.

 // OK import { apiClient } from '#shared/api/index.js'; // Error: Cannot find module '#src/shared/api/index' or its corresponding type declarations. import { apiClient } from '#shared/api/index'; // Error: Cannot find module '#src/shared/api' or its corresponding type declarations. import { apiClient } from '#shared/api'; // Error: Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Did you mean './relative.js'? import { foo } from './relative';

내 프로젝트의 대부분은 번들러를 사용하여 코드를 작성하고 모듈을 가져올 때 파일 확장자를 추가하지 않기 때문에 모든 가져오기를 다시 작성하고 싶지 않았습니다. 이 제한 사항을 해결하기 위해 다음과 같이 프로젝트를 구성하는 방법을 찾았습니다.

 { "name": "my-awesome-project", "imports": { "#*": [ "./src/*", "./src/*.ts", "./src/*.tsx", "./src/*.js", "./src/*.jsx", "./src/*/index.ts", "./src/*/index.tsx", "./src/*/index.js", "./src/*/index.jsx" ] } }

이 구성을 사용하면 확장을 지정할 필요 없이 모듈을 가져오는 일반적인 방법이 가능합니다. 이는 가져오기 경로가 디렉터리를 가리키는 경우에도 작동합니다.

 // OK import { apiClient } from '#shared/api/index.js'; // OK import { apiClient } from '#shared/api/index'; // OK import { apiClient } from '#shared/api'; // Error: Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Did you mean './relative.js'? import { foo } from './relative';

상대 경로를 사용하여 가져오는 것과 관련된 한 가지 남은 문제가 있습니다. 이 문제는 경로 별칭과 관련이 없습니다. nodenext 모드를 사용하도록 모듈 확인을 구성했기 때문에 TypeScript에서 오류가 발생합니다.

운 좋게도 최근 TypeScript 5.0 릴리스 에는 가져오기 내부의 전체 경로를 지정할 필요가 없는 새로운 모듈 확인 모드가 추가되었습니다. 이 모드를 활성화하려면 tsconfig.json 파일에서 몇 가지 옵션을 구성해야 합니다.

 { "compilerOptions": { /* Specify what module code is generated. */ "module": "esnext", /* Specify how TypeScript looks up a file from a given module specifier. */ "moduleResolution": "bundler" } }

설정을 완료한 후에는 상대 경로 가져오기가 평소대로 작동합니다.

 // OK import { apiClient } from '#shared/api/index.js'; // OK import { apiClient } from '#shared/api/index'; // OK import { apiClient } from '#shared/api'; // OK import { foo } from './relative';

이제 가져오기 경로 작성 방법에 대한 추가 제한 없이 imports 필드를 통해 경로 별칭을 완전히 활용할 수 있습니다.

TypeScript로 코드 작성

tsc 컴파일러를 사용하여 소스 코드를 빌드할 때 추가 구성이 필요할 수 있습니다. TypeScript의 한 가지 제한 사항은 imports 필드를 사용할 때 CommonJS 모듈 형식으로 코드를 작성할 수 없다는 것입니다.

따라서 Node.js에서 컴파일된 코드를 실행하려면 ESM 형식으로 코드를 컴파일하고 package.json 에 type 필드를 추가해야 합니다.

 { "name": "my-awesome-project", "type": "module", "imports": { "#*": "./src/*" } }

코드가 build/ 와 같은 별도의 디렉터리로 컴파일된 경우 경로 별칭이 src/ 와 같은 원래 위치를 가리키기 때문에 Node.js에서 모듈을 찾지 못할 수 있습니다. 이 문제를 해결하기 위해 package.json 파일에서 조건부 가져오기 경로를 사용할 수 있습니다.

이를 통해 이미 빌드된 코드를 src/ 디렉터리 대신 build/ 디렉터리에서 가져올 수 있습니다.

 { "name": "my-awesome-project", "type": "module", "imports": { "#*": { "default": "./src/*", "production": "./build/*" } } }

특정 가져오기 조건을 사용하려면 --conditions 플래그를 사용하여 Node.js를 시작해야 합니다.

 node --conditions=production build/index.js

코드 번들러의 하위 경로 가져오기 지원

코드 번들러는 일반적으로 Node.js에 내장된 모듈 확인 구현이 아닌 자체 모듈 확인 구현을 사용합니다. 따라서 imports 필드에 대한 지원을 구현하는 것이 중요합니다.

내 프로젝트에서 Webpack, Rollup 및 Vite를 사용하여 경로 별칭을 테스트했으며 결과를 공유할 준비가 되었습니다.

번들러를 테스트하는 데 사용한 경로 별칭 구성은 다음과 같습니다. 가져오기 내 파일의 전체 경로를 지정하지 않아도 되도록 TypeScript와 동일한 트릭을 사용했습니다.

 { "name": "my-awesome-project", "type": "module", "imports": { "#*": [ "./src/*", "./src/*.ts", "./src/*.tsx", "./src/*.js", "./src/*.jsx", "./src/*/index.ts", "./src/*/index.tsx", "./src/*/index.js", "./src/*/index.jsx" ] } }

웹팩

Webpack은 v5.0부터 imports 필드를 지원합니다 . 경로 별칭은 추가 구성 없이 작동합니다. TypeScript를 사용하여 테스트 프로젝트를 빌드하는 데 사용한 Webpack 구성은 다음과 같습니다.

 const config = { mode: 'development', devtool: false, entry: './src/index.ts', module: { rules: [ { test: /\.tsx?$/, use: { loader: 'babel-loader', options: { presets: ['@babel/preset-typescript'], }, }, }, ], }, resolve: { extensions: ['.ts', '.tsx', '.js', '.jsx'], }, }; export default config;

비테

imports 필드에 대한 지원이 Vite 버전 4.2.0에 추가되었습니다 . 하지만 버전 4.3.3에서는 중요한 버그가 수정되었으므로 최소한 이 버전을 사용하는 것이 좋습니다. Vite에서 경로 별칭은 dev 및 build 모드 모두에서 추가 구성 없이 작동합니다.

그래서 저는 완전히 빈 구성으로 테스트 프로젝트를 구축했습니다.

롤업

Rollup은 Vite 내부에서 사용되지만 imports 필드는 기본적으로 작동하지 않습니다. 이를 활성화하려면 @rollup/plugin-node-resolve 플러그인 버전 11.1.0 이상을 설치해야 합니다. 구성 예시는 다음과 같습니다.

 import { nodeResolve } from '@rollup/plugin-node-resolve'; import { babel } from '@rollup/plugin-babel'; export default [ { input: 'src/index.ts', output: { name: 'mylib', file: 'build.js', format: 'es', }, plugins: [ nodeResolve({ extensions: ['.ts', '.tsx', '.js', '.jsx'], }), babel({ presets: ['@babel/preset-typescript'], extensions: ['.ts', '.tsx', '.js', '.jsx'], }), ], }, ];

불행하게도 이 구성에서는 경로 별칭이 Node.js의 제한 내에서만 작동합니다. 이는 확장자를 포함한 전체 파일 경로를 지정해야 함을 의미합니다. Rollup은 배열의 첫 번째 경로만 사용하므로 imports 필드 내에 배열을 지정해도 이 제한을 우회할 수 없습니다.

나는 Rollup 플러그인을 사용하여 이 문제를 해결하는 것이 가능하다고 생각하지만, 주로 작은 라이브러리에 Rollup을 사용하기 때문에 그렇게 해보지는 않았습니다. 내 경우에는 프로젝트 전체에서 가져오기 경로를 다시 작성하는 것이 더 쉬웠습니다.

테스트 실행기에서 하위 경로 가져오기 지원

테스트 실행기는 모듈 확인 메커니즘에 크게 의존하는 또 다른 개발 도구 그룹입니다. 코드 번들러와 유사하게 자체 모듈 확인 구현을 사용하는 경우가 많습니다. 결과적으로 imports 필드가 예상대로 작동하지 않을 가능성이 있습니다.

다행히도 제가 테스트한 도구는 잘 작동했습니다. Jest v29.5.0 및 Vite v0.30.1을 사용하여 경로 별칭을 테스트했습니다. 두 경우 모두 경로 별칭은 추가 설정이나 제한 없이 원활하게 작동했습니다. Jest는 버전 v29.4.0부터 imports 필드를 지원했습니다 .

Vitest의 지원 수준은 Vite 버전에만 의존하며 Vite 버전은 v4.2.0 이상이어야 합니다.

코드 편집기에서 하위 경로 가져오기 지원

인기 있는 라이브러리의 imports 필드는 현재 잘 지원됩니다. 그러나 코드 편집기는 어떻습니까? 경로 별칭을 사용하는 프로젝트에서 코드 탐색, 특히 "정의로 이동" 기능을 테스트했습니다. 코드 편집기에서 이 기능을 지원하면 몇 가지 문제가 있는 것으로 나타났습니다.

VS 코드

VS Code의 경우 TypeScript 버전이 중요합니다. TypeScript 언어 서버는 JavaScript 및 TypeScript 코드를 분석하고 탐색하는 역할을 담당합니다.

설정에 따라 VS Code는 내장된 TypeScript 버전이나 프로젝트에 설치된 버전을 사용합니다.

TypeScript v5.0.4와 함께 VS Code v1.77.3에서 imports 필드 지원을 테스트했습니다.

VS Code에는 경로 별칭과 관련하여 다음과 같은 문제가 있습니다.

1. TypeScript는 모듈 해상도 설정이 nodenext 또는 bundler 로 설정될 때까지 imports 필드를 사용하지 않습니다. 따라서 VS Code에서 사용하려면 프로젝트에서 모듈 해상도를 지정해야 합니다.

   
   

2. IntelliSense는 현재 imports 필드를 사용한 가져오기 경로 제안을 지원하지 않습니다. 이 문제에 대한 공개 문제가 있습니다.

두 문제를 모두 우회하려면 tsconfig.json 파일에서 경로 별칭 구성을 복제할 수 있습니다. TypeScript를 사용하지 않는 경우 jsconfig.json 에서 동일한 작업을 수행할 수 있습니다.

 // tsconfig.json OR jsconfig.json { "compilerOptions": { "baseUrl": "./", "paths": { "#*": ["./src/*"] } } } // package.json { "name": "my-awesome-project", "imports": { "#*": "./src/*" } }

웹스톰

버전 2021.3(2022.3.4에서 테스트)부터 WebStorm은 imports 필드를 지원합니다 . WebStorm은 자체 코드 분석기를 사용하므로 이 기능은 TypeScript 버전과 독립적으로 작동합니다. 그러나 WebStorm에는 경로 별칭 지원과 관련하여 별도의 문제가 있습니다.

1. 편집기는 경로 별칭 사용에 대해 Node.js에서 부과한 제한 사항을 엄격하게 따릅니다. 파일 확장명이 명시적으로 지정되지 않으면 코드 탐색이 작동하지 않습니다. index.js 파일을 사용하여 디렉터리를 가져오는 경우에도 동일하게 적용됩니다.

   
   

2. WebStorm에는 imports 필드 내에서 경로 배열을 사용하지 못하게 하는 버그가 있습니다. 이 경우 코드 탐색이 완전히 작동하지 않습니다.

 { "name": "my-awesome-project", // OK "imports": { "#*": "./src/*" }, // This breaks code navigation "imports": { "#*": ["./src/*", "./src/*.ts", "./src/*.tsx"] } }

다행히도 VS Code의 모든 문제를 해결하는 동일한 방법을 사용할 수 있습니다. 특히 tsconfig.json 또는 jsconfig.json 파일에서 경로 별칭 구성을 복제할 수 있습니다. 이를 통해 아무런 제한 없이 경로 별칭을 사용할 수 있습니다.

권장 구성

다양한 프로젝트에서 imports 필드를 사용한 실험과 경험을 바탕으로 다양한 프로젝트 유형에 가장 적합한 경로 별칭 구성을 식별했습니다.

TypeScript나 번들러 없이

이 구성은 추가 빌드 단계 없이 Node.js에서 소스 코드가 실행되는 프로젝트를 위한 것입니다. 이를 사용하려면 다음 단계를 따르십시오.

1. package.json 파일에서 imports 필드를 구성합니다. 이 경우에는 매우 기본적인 구성이면 충분합니다.

   
   

2. 코드 편집기에서 코드 탐색이 작동하려면 jsconfig.json 파일에서 경로 별칭을 구성해야 합니다.

 // jsconfig.json { "compilerOptions": { "baseUrl": "./", "paths": { "#*": ["./src/*"] } } } // package.json { "name": "my-awesome-project", "imports": { "#*": "./src/*" } }

TypeScript를 사용하여 코드 빌드

이 구성은 소스 코드가 TypeScript로 작성되고 tsc 컴파일러를 사용하여 빌드되는 프로젝트에 사용해야 합니다. 이 구성에서는 다음을 구성하는 것이 중요합니다.

1. package.json 파일의 imports 필드입니다. 이 경우 Node.js가 컴파일된 코드를 올바르게 확인하도록 조건부 경로 별칭을 추가해야 합니다.

   
   

2. TypeScript는 imports 필드를 사용할 때 ESM 형식의 코드만 컴파일할 수 있으므로 package.json 파일에서 ESM 패키지 형식을 활성화해야 합니다.

   
   

3. tsconfig.json 파일에서 ESM 모듈 형식과 moduleResolution 설정합니다. 이렇게 하면 TypeScript가 가져오기에서 잊어버린 파일 확장자를 제안할 수 있습니다. 파일 확장자를 지정하지 않으면 컴파일 후 코드가 Node.js에서 실행되지 않습니다.

   
   

4. 코드 편집기에서 코드 탐색을 수정하려면 tsconfig.json 파일에서 경로 별칭을 반복해야 합니다.

 // tsconfig.json { "compilerOptions": { "module": "esnext", "moduleResolution": "nodenext", "baseUrl": "./", "paths": { "#*": ["./src/*"] }, "outDir": "./build" } } // package.json { "name": "my-awesome-project", "type": "module", "imports": { "#*": { "default": "./src/*", "production": "./build/*" } } }

번들러를 사용하여 코드 작성

이 구성은 소스 코드가 번들로 제공되는 프로젝트를 위한 것입니다. 이 경우 TypeScript는 필요하지 않습니다. 존재하지 않는 경우 jsconfig.json 파일에서 모든 설정을 설정할 수 있습니다.

이 구성의 주요 기능은 가져오기에서 파일 확장자를 지정하는 것과 관련된 Node.js 제한 사항을 우회할 수 있다는 것입니다.

다음을 구성하는 것이 중요합니다.

1. package.json 파일에서 imports 필드를 구성합니다. 이 경우 각 별칭에 경로 배열을 추가해야 합니다. 이렇게 하면 번들러가 파일 확장자를 지정하지 않고도 가져온 모듈을 찾을 수 있습니다.

   
   

2. 코드 편집기에서 코드 탐색을 수정하려면 tsconfig.json 또는 jsconfig.json 파일에서 경로 별칭을 반복해야 합니다.

 // tsconfig.json { "compilerOptions": { "baseUrl": "./", "paths": { "#*": ["./src/*"] } } } // package.json { "name": "my-awesome-project", "imports": { "#*": [ "./src/*", "./src/*.ts", "./src/*.tsx", "./src/*.js", "./src/*.jsx", "./src/*/index.ts", "./src/*/index.tsx", "./src/*/index.js", "./src/*/index.jsx" ] } }

결론

imports 필드를 통해 경로 별칭을 구성하는 것은 타사 라이브러리를 통해 구성하는 것과 비교할 때 장단점이 있습니다. 이 접근 방식은 일반적인 개발 도구(2023년 4월 기준)에서 지원되지만 제한 사항도 있습니다.

이 방법은 다음과 같은 이점을 제공합니다.

• "즉시" 코드를 컴파일하거나 트랜스파일할 필요 없이 경로 별칭을 사용하는 기능.

• 가장 널리 사용되는 개발 도구는 추가 구성 없이 경로 별칭을 지원합니다. 이는 Webpack, Vite, Jest 및 Vitest에서 확인되었습니다.

• 이 접근 방식은 예측 가능한 하나의 위치( package.json 파일)에서 경로 별칭 구성을 촉진합니다.

• 경로 별칭을 구성하는 데에는 타사 라이브러리를 설치할 필요가 없습니다.

그러나 개발 도구가 발전함에 따라 제거될 일시적인 단점이 있습니다.

• 인기 있는 코드 편집기라도 imports 필드를 지원하는 데 문제가 있습니다. 이러한 문제를 방지하려면 jsconfig.json 파일을 사용할 수 있습니다. 그러나 이로 인해 두 파일의 경로 별칭 구성이 중복됩니다.

• 일부 개발 도구는 기본적으로 imports 필드에서 작동하지 않을 수 있습니다. 예를 들어 Rollup을 사용하려면 추가 플러그인을 설치해야 합니다.

• Node.js의 imports 필드를 사용하면 가져오기 경로에 새로운 제약 조건이 추가됩니다. 이러한 제약 조건은 ES 모듈의 제약 조건과 동일하지만 imports 필드 사용을 시작하기가 더 어려울 수 있습니다.

• Node.js 제약조건으로 인해 Node.js와 다른 개발 도구 간의 구현 차이가 발생할 수 있습니다. 예를 들어 코드 번들러는 Node.js 제약 조건을 무시할 수 있습니다. 이러한 차이점은 특히 TypeScript를 설정할 때 구성을 복잡하게 만들 수 있습니다.

그렇다면 imports 필드를 사용하여 경로 별칭을 구성하는 것이 가치가 있습니까? 저는 새로운 프로젝트의 경우 타사 라이브러리 대신 이 방법을 사용할 가치가 있다고 생각합니다.

imports 필드는 기존 구성 방법에 비해 상당한 이점을 제공하므로 앞으로 많은 개발자를 위한 경로 별칭을 구성하는 표준 방법이 될 가능성이 높습니다.

그러나 경로 별칭이 구성된 프로젝트가 이미 있는 경우 imports 필드로 전환해도 큰 이점을 얻을 수 없습니다.

이 기사에서 새로운 것을 배웠기를 바랍니다. 읽어 주셔서 감사합니다!

유용한 링크

1. 내보내기 및 가져오기 구현을 위한 RFC
2. 수입 분야의 능력을 더 잘 이해하기 위한 일련의 테스트
3. Node.js의 imports 필드에 대한 문서
4. ES 모듈의 가져오기 경로에 대한 Node.js 제한 사항

여기에도 게시됨