최적의 JS 모듈을 개발하는 방법

이번에는 최적의 JS 모듈 개발 방법과 최적의 JS 모듈 개발을 위한 주의 사항에 대해 알려드리겠습니다. 실제 사례를 살펴보겠습니다.

많은 사람들이 npm에 자신만의 JavaScript 모듈을 게시했습니다. 일부 모듈을 사용하는 과정에서 "이 모듈은 매우 유용하지만 xxx할 수 있으면 더 좋을 것 같다"는 생각이 들곤 합니다. 따라서 이 글에서는 모듈 사용자의 관점에서 모듈을 더욱 유용하게 만드는 방법을 요약해 보겠습니다.

ES6 모듈에 대한 입구 제공

웹팩과 롤업 모두 ES6 모듈에 대한 일부 정적 최적화(예: Tree Shaking 및 Scope)를 지원합니다. 호이스팅), 먼저 ES6 모듈의 입구인 package.json의 모듈 필드를 읽습니다. 기본 필드는 CommonJS 모듈의 진입점 역할을 합니다. 일반적인 접근 방식은 ES6 구문을 사용하여 소스 코드를 작성한 다음 구문 변환 도구와 결합된 모듈 패키징 도구를 사용하여 생성하는 것입니다. CommonJS 모듈과 ES6 모듈로, 메인 필드와 모듈 필드를 모두 제공할 수 있습니다.

TypeScript 유형 선언 파일 제공

사용자가 TypeScript를 사용하지만 모듈이 선언 파일을 제공하지 않는 경우 TypeScript를 피하기 위해 프로젝트에 코드 조각을 추가해야 합니다. 또한 컴파일 오류는 대부분의 코드 편집기(Webstorm, VS Code 등)에서 인식하므로 TypeScript 사용자에게만 사용자 친화적인 것은 아닙니다. TypeScript의 유형 선언은 보다 정확한 코드 힌트를 제공하고 사용자가 잘못된 수 또는 유형의 매개변수를 전달할 때 사용자에게 메시지를 표시할 수 있습니다.

모범 사례는 TypeScript를 사용하는 것입니다. 모듈을 작성하면 컴파일 타임에 유형 선언이 자동으로 생성됩니다. 또한 설명서를 참조하여 선언 파일을 수동으로 유지 관리할 수도 있습니다. 모듈 루트 디렉터리에 index.d.ts를 추가할 수 있습니다. 파일을 생성하거나 package.json에서 입력 필드를 선언하여 선언 파일의 위치를 ​​제공합니다.

모듈이 Node.js와 브라우저에서 동시에 실행되도록 하세요

window라는 전역 변수(예: !!typeof window)가 있는지 감지하여 모듈이 현재 Node.js 또는 브라우저에서 실행 중인지 확인한 다음 다양한 방법을 사용하여 기능을 구현할 수 있습니다.

이 방법은 비교적 일반적이지만 사용자가 모듈 패키징 도구를 사용하는 경우 Node.js가 브라우저 구현은 최종 출력 파일에 포함됩니다. 이 문제에 대한 대응으로 오픈 소스 커뮤니티에서는 package.json에 브라우저를 추가할 것을 제안했습니다. 현재 웹팩과 롤업 모두에서 필드 제안이 이미 이 필드를 지원하고 있습니다.

브라우저 필드는 두 가지 방법으로 사용할 수 있습니다:

브라우저 측에서 사용될 때 모듈 항목으로 브라우저 필드에 파일 경로를 제공하십시오. 그러나 패키징 도구는 브라우저 필드에 모듈 항목으로 지정된 파일 경로를 사용하는 데 우선순위를 부여하므로 모듈이 필드는 무시됩니다. 결과적으로 패키징 도구는 코드를 최적화하지 않습니다. 자세한 내용은 이 질문을 참조하세요.

파일 중 일부만 바꾸려면 개체를 선언하면 됩니다.

예를 들어, 모듈에 http.js와 xhr.js라는 두 개의 파일이 있다고 가정합니다. 첫 번째 파일은 Node.js에서 http를 사용합니다. 모듈은 요청을 시작하고 다른 모듈은 브라우저에서 XMLHTTPRequest를 사용하여 동일한 기능을 구현합니다. 적절한 파일을 사용하려면 모듈 코드가 항상 require('./path/to/http.js') 및 package.json에서 선언:

{
 "browser": {
  "./path/to/http.js": "./path/to/xhr.js"
 }
}

이러한 방식으로 모듈이 패키징 도구에서 사용될 때 패키징 도구는 최종 출력 파일에 xhr.js 코드만 포함합니다.

다양한 서비스로 프로젝트를 무장하세요

대부분의 JavaScript 프로젝트는 오픈 소스이며 오픈 소스 커뮤니티는 프로젝트에 더 강력한 도움을 제공할 수 있는 오픈 소스 프로젝트를 위한 다양한 무료 서비스도 제공합니다. 다음은 보다 일반적으로 사용되는 몇 가지 서비스입니다.

프로젝트에서 가장 일반적으로 사용되는 서비스는 지속적 통합입니다. 지속적 통합 서비스는 테스트, 코드 스타일 감지, 패키징 등의 작업을 서버에 배치하고 코드를 제출할 때 자동으로 실행할 수 있습니다. Travis CI, CircleCI 및 AppVeyor. Travis CI는 오픈 소스 프로젝트에 무료이며 Linux 및 OS X에서 사용할 수 있습니다. 실행 환경; CircleCI는 오픈 소스 및 개인 프로젝트 모두에 대해 무료이지만 AppVeyor는 Windows를 제공하는 데 1500분의 런타임 제한이 있습니다. 오픈 소스 프로젝트의 경우 운영 환경도 무료입니다.

테스트를 실행한 후 Coveralls에 테스트 적용 범위를 업로드할 수도 있습니다. 이 서비스를 사용하면 온라인으로 코드의 테스트 범위를 찾아볼 수 있습니다.

다양한 브라우저와 플랫폼의 다양한 버전에서 모듈을 완전히 테스트하려면 Sauce Labs와 BrowserStack을 사용할 수도 있습니다. 두 가지 모두 오픈 소스 프로젝트에 대해 무료이지만 신청하려면 이메일을 보내야 합니다.

마지막으로 Shields IO는 npm 버전 번호, 다운로드 볼륨, 테스트 통과 상태, 테스트 적용 범위, 파일 크기, 종속성이 최신인지 여부 등을 포함하되 이에 국한되지 않고 프로젝트에 대한 많은 추가 정보를 제공할 수 있는 다양한 아이콘을 제공합니다. 등.

이 기사의 사례를 읽은 후 방법을 마스터했다고 생각합니다. 더 흥미로운 정보를 보려면 PHP 중국어 웹사이트의 다른 관련 기사를 주목하세요!

추천 자료:

webpack+express를 사용하여 다중 페이지 사이트 개발을 구현하는 단계

Webpack 프레임워크 사용 요약

위 내용은 최적의 JS 모듈을 개발하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!