이것이 가능한지 또는 Node.js 저장소에 속하는지 확실하지 않습니다.

뭐? 왜

특정 종속성이 모든 환경에서 제대로 작동하려면 특정 빌드 구성이 필요한 경우가 종종 있습니다(예:).

이 구성은 Babel 구성, Webpack 구성 또는 해당 패키지에 대한 사용자 정의가 될 수 있습니다.

현재로서는 패키지를 구성하는 표준화된 방법이 없습니다.

어떤 사람들은 패키지 이름을 따서 package.json 필드를 배치하고 패키지가 읽을 수 있는 규칙을 사용합니다. 그러나 그것은 충분히 표준적인 느낌이 들지 않습니다.

언제

패키지에 런타임 또는 빌드 시간에 대한 사용자 지정 구성이 필요한 경우.

어디에

어떻게

JavaScript가 특정 경우에 빌드 단계를 필요로 하는 경우가 있습니다. 이 구성 기능에는 모든 패키지에 전달할 수 있는 선택적 "빌드 종속성" 옵션이 있습니다(네이티브 모듈을 빌드하거나 JavaScript를 하위 형식으로 변환).

구성에 따라 패키지에는 필요하지 않은 특정 종속성이 필요할 수 있습니다(fe 빌드 종속성).

따라서 패키지 시스템은 사용자가 특정 패키지 구성을 가지고 있는 경우 설치할 추가 종속성을 결정할 수 있다는 점에서 충분히 똑똑할 것입니다.

아마도 이 기능은 기존 네이티브 모듈 시스템에서 전체 JavaScript 시스템으로 확장되어야 할 수도 있습니다(사용하기 쉬운 방식으로 네이티브 모듈은 까다롭습니다).

이는 선택적 종속성과 같은 경우에도 매우 유용할 수 있습니다. 그것은 지정하려면 설정으로, 쉬운 것입니다 그 (예를 들어) 라이브러리를 사용 three 대신 babylonjs . 그러면 적절한 종속성이 설치됩니다. 피어 종속성과 비슷하지만 더 쉽고 선택적 deps에 의존하는 주어진 패키지에는 특정 조건이 지정되었는지 여부를 결정하기 위해 구성 API에 안정적으로 액세스하는 표준 방법이 있습니다(현재로서는 까다롭고 node_modules의 모든 낭포 순회는 이 경우 표준).

현재 행동

• 해당 없음

예상되는 동작

• 높은 수준에서 위의 내용을 다룹니다.

또 다른 예로, 때때로 패키지 소비자는 다른 방식으로 코드를 컴파일하기 위해 일반적인 컴파일된 출력 대신 패키지 소스를 사용해야 합니다.

일반적으로 NPM이 지금까지 일반적인 처리 방법을 제공하지 않는 그런 종류의 문제가 있습니다.

누구

패키지 작성자 및 해당 사용자

참고문헌

• 해당 없음