오늘날 클라이언트 측 자바 스크립트 라이브러리를 모듈화하고 패키징하는 방법은 무엇입니까?

나는 현대 클라이언트 측 JS 생태계를 따라 잡고 CommonJS와 AMD (브라우저 화, requirejs, onejs, jam, 수십 가지 관련 도구 포함)를 읽었습니다. Javascript 라이브러리를 작성하는 경우 가장 광범위하게 액세스 할 수 있도록 모듈화 / 패키징하는 방법은 무엇입니까 (특히 CommonJS, AMD, 특히 둘 다 맹세하는 사용자가)?

jQuery와 같은 인기있는 라이브러리는 자체 빌드를 위해 구식 파일 연결을 사용 exports하고 전역 컨텍스트에 쓸지 여부를 동적으로 감지하는 것 같습니다 . 나는 현재 같은 일을하고 있지만 주된 단점은 (jQuery와 달리) 몇 개의 라이브러리에 의존하는 경우 사용자에게 전이 세트를 수동으로 사전 포함하도록 요구하지 않아도된다는 것입니다. (현재는 두 가지 종속성이 있습니다.) 물론 전역 네임 스페이스 오염.

아니면 각 컨텍스트마다 여러 버전의 라이브러리를 생성하는 것이 가장 깨끗합니까?

나는 또한 포장과 출판에 대해 궁금합니다. 여러 시스템이 있지만 주요 시스템은 바우어라고 생각합니다. 페치이기 때문에 처리하기 쉽습니다. 그러나 CommonJS가 필요한 구성 요소와 같은 다른 패키지 시스템을 대상으로 삼아야하는지 궁금합니다.

내가 알아야 할 다른 관련 측면이 있습니까? 이 모든 것에 대해 모범적 인 프로젝트가 있습니까?

난 항상 빌드 파일을 사용하는 데 사용했지만 내가 시작한 이후 처음 nodejs 내가 사용하기 시작 프로젝트 browserify . browerify 및 기타 유사한 라이브러리를 사용하면 코드가 빌드 파일입니다. 둘 다에서 실행할 수 있지만 순수한 클라이언트 코드로도 작동 할 수있는 클라이언트 및 서버 라이브러리를 이용하고 있습니다. 요약하면 browserify는 노드에 코드를 작성하는 이점 (전역, npm, 간단한 요구를 피하는 anon 함수 없음)을 모두 제공하며 하나의 명령으로 클라이언트에서 실행되도록 코드를 패키지하고 하나의 파일 만로드 할 수 있습니다.

browserify를 사용하면 (named app.js)와 같은 작업을 수행 할 수 있습니다.

var MyLib = require('../myLib');

if(typeof window !== 'undefined') {
    window.MyLib = MyLib;
    window._ = require('underscore');
    window.$ = require('$');
    window.MyLib.myCan = require('./3rdParty/can/can');
}

browserify app.js> client.js

다음과 같은 것을 생성 할 것입니다 :

[function(require,module,exports){
    window.MyLib = //MyLib code
},
function(require,module,exports){
     window._ = //_ code
},
function(require,module,exports){
    window.$ = //$ code
},
function(require,module,exports){
    window.MyLib.myCan = //can code
}

정의한 파일에는 모든 타사 라이브러리가 포함되어 있으며이를 사용하는 개발자와 충돌하지 않을 수 있습니다.

-의견에 대한 답변으로 편집 (및 질문에 대한 완전한 미스)

나는 그것이 당신의 의존성과 모든 버전과 라이브러리에서 작동하도록 얼마나 많은 시간을 소비하고 싶은지에 달려 있다고 생각합니다. 종속성이 공통적이며 버전마다 동일한 API를 따르는 경우 백본 경로로 이동하여 사용자에게 $ 및 _가 필요합니다. 번들 파일의 일부로 더 모호한 라이브러리를 넣는 것이 좋습니다. 옵션도 잘라서 건조 할 필요가 없습니다. 사전 빌드를 제공하거나 자체 패키지를 빌드 할 수 있습니다.

클라이언트 측 라이브러리의 종류 :

1. DOM을 터치
2. DOM을 만지지 않습니다

첫 번째 종류 (UI 위젯 등)에서는 일반적으로 jQuery가 있다고 가정합니다. "DOM 라이브러리 불가지론"을 작성하여 덜 인기있는 것들과도 작동시킬 수는 있지만 귀찮게하지는 않습니다.

두 번째 종류로. 우선, jQuery 플러그인으로 만들지 마십시오. 예를 들어 "jQuery 쿠키 플러그인"은 말도 안되지만 그러한 라이브러리는 실제로 존재합니다.

이러한 종류의 두 가지 모두 종속성, 작은 종속성 또는 큰 종속성이 없을 수 있습니다. DOM 라이브러리는 이러한 의미에서 종속성으로 계산되지 않습니다. 처음 2를 사용하면 라이브러리 범위 내에서 연결하고 중복 가능성에 대해 걱정하지 않아도됩니다. 예를 들어, jQuery isArrayLike는 사용자가 임의의 유틸리티 벨트 라이브러리에 이미 포함되어 있어도 내부 기능을 연결합니다 .

라이브러리 (실제로 언어)를 개발할 때 큰 의존성을 가진 개인적인 경험이 하나 있습니다 moment.js. 이 경우에는 2 개의 빌드를 제공 할 것입니다. 하나는 moment.js가 연결되어 있고 다른 하나는 포함하지 않아도됩니다. 그래도 이것이 좋은 해결책인지는 모르겠습니다.

그리고 그렇습니다. 모든 경우에, 단지 작동하는 하나의 최종 큰 파일을 작성하는 jQuery 접근 방식이 취해집니다. 하단에 모듈 상용구가 있습니다 (필요 / AMD / 글로벌 등 감지).