Làm cách nào để mô đun hóa và đóng gói thư viện Javascript phía máy khách ngày hôm nay?


11

Tôi đã bắt kịp với hệ sinh thái JS phía máy khách hiện đại và đọc trên CommonJS và AMD (bao gồm các công cụ liên quan - browserify, requestjs, onejs, jam, hàng tá thứ khác). Nếu tôi đang viết thư viện Javascript, làm cách nào để tôi mô đun hóa / gói nó sao cho có thể truy cập rộng rãi nhất (lý tưởng nhất là bởi những người dùng đã chửi bới CommonJS, AMD và đặc biệt là không)?

Các thư viện phổ biến như jQuery dường như chỉ sử dụng cách ghép tệp trường cũ để tự xây dựng và tự động phát hiện xem nó có nên ghi vào exportsbối cảnh toàn cầu hay không. Tôi hiện đang làm điều tương tự, nhưng nhược điểm chính là nếu tôi (không giống như jQuery) phụ thuộc vào một vài thư viện, thật tuyệt khi không phải yêu cầu người dùng bao gồm trước bộ thủ công. (Mặc dù hiện tại tôi chỉ có hai phụ thuộc.) Và tất nhiên là ô nhiễm không gian tên toàn cầu.

Hoặc có lẽ là sạch nhất để tạo nhiều phiên bản thư viện của tôi, cho từng bối cảnh?

Tôi cũng đang tự hỏi về bao bì và xuất bản. Có một số hệ thống, nhưng tôi tin rằng hệ thống chính là bower, dễ xử lý vì tất cả những gì nó làm là tìm nạp. Tuy nhiên, tôi tự hỏi liệu tôi cũng nên nhắm mục tiêu các hệ thống gói khác như thành phần (yêu cầu CommonJS).

Có những khía cạnh liên quan khác mà tôi nên biết? Có bất kỳ dự án ví dụ tốt để làm theo cho tất cả điều này?


Đây là một hướng dẫn tuyệt vời: youtube.com/watch?v=USk1ie30z5k Chàng trai đề cập đến các yêu cầu (r.js), nút, bower, xương sống, ...

@MattFenwick Tôi đã sử dụng tất cả các công cụ được đề cập; video không trả lời bất kỳ câu hỏi nào của tôi.
Dương

Bạn đã xem nó chưa? Tôi dường như nhớ anh chàng dẫn chúng tôi đi qua một thư viện và giải thích các dòng mã cụ thể làm cho nó hoạt động với nhiều hệ thống mô-đun mà không yêu cầu bất kỳ trong số chúng.

Câu trả lời:


2

Tôi đã luôn sử dụng các tệp xây dựng nhưng kể từ khi tôi bắt đầu dự án nodejs đầu tiên của mình, tôi bắt đầu sử dụng browserify . Với browerify và các thư viện tương tự khác, mã của bạn là tệp xây dựng của bạn. Tôi đang tận dụng một thư viện máy khách và máy chủ có thể chạy trên cả hai nhưng nó cũng có thể hoạt động với mã máy khách hoàn toàn. Tóm lại, browserify cung cấp cho bạn tất cả các lợi ích của việc viết mã trong nút (không có chức năng anon để tránh toàn cầu, npm, yêu cầu đơn giản) và nó cho phép bạn đóng gói mã đó để chạy trên máy khách bằng một lệnh và chỉ tải một tệp.

Với browserify, bạn có thể làm một cái gì đó như (tên 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');
}

trình duyệt app.js> client.js

Sẽ tạo ra một cái gì đó như:

[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
}

Tệp mà bạn sẽ xác định có thể bao gồm tất cả các lib của bên thứ 3 và không xung đột với bất kỳ nhà phát triển nào sử dụng nó.

- Chỉnh sửa để trả lời nhận xét (và hoàn toàn bỏ lỡ câu hỏi)

Tôi đoán điều đó sẽ phụ thuộc vào sự phụ thuộc của bạn và thời gian bạn muốn dành để đảm bảo chúng hoạt động trên tất cả các phiên bản và lib. Nếu các phụ thuộc của bạn là phổ biến và theo cùng một api từ phiên bản này sang phiên bản khác, bạn có thể đi theo tuyến đường trục và chỉ yêu cầu người dùng phải có $ và _. Tôi sẽ đề nghị đặt các lib tối nghĩa hơn như là một phần của tệp được đóng gói. Các tùy chọn không phải được cắt và làm khô. Bạn có thể cung cấp một gói dựng sẵn hoặc xây dựng gói của riêng bạn.


+1 cho trình duyệt, nhiều người cần biết về công cụ đó
Benjamin Gruenbaum

@BenjaminGruenbaum Đây là một công cụ thực sự tuyệt vời. Tôi rất may mắn tôi đã kiểm tra lại. Ban đầu tôi đã bỏ qua nó vì nó được sử dụng để tải các tệp không đồng bộ có thể kích hoạt N # tải tệp trong trình duyệt. Bây giờ chỉ có một và bản đồ nguồn có thể được kích hoạt.
vui mừng

1
Xem, đây là vấn đề - Tôi đang hỏi về cách xuất bản một thư viện. Tôi thực sự biết về browserify / onejs / các hệ thống dựa trên CommonJS khác, nhưng nếu tôi bắt đầu sử dụng require()mã của mình, điều đó có nghĩa là người dùng sẽ không thể truy cập được nữa trừ khi họ thay đổi dự án của riêng họ để sử dụng CommonJS. Nếu tôi phát hành một tập lệnh được biên dịch, thì nó sẽ bao gồm khả năng bao gồm các phần phụ thuộc dự phòng với dự án của riêng chúng và có khả năng làm phình to khả năng phân phối (ví dụ như nhiều câu hỏi).
Dương

0

Các loại thư viện phía khách hàng:

  1. Chạm vào DOM
  2. Không chạm vào DOM

Với loại đầu tiên (widget UI, v.v.), thông thường bạn sẽ cho rằng jQuery có mặt. Bạn cũng có thể viết "bất khả tri thư viện DOM" và để nó hoạt động với những thứ ít phổ biến hơn nhưng tôi không bận tâm.

Với loại thứ hai. Trước hết, đừng biến nó thành một plugin jQuery, ví dụ "Plugin cookie jQuery" thật lố bịch nhưng một thư viện như vậy thực sự tồn tại.

Cả hai loại này có thể không có phụ thuộc, phụ thuộc nhỏ hoặc phụ thuộc lớn - với một thư viện dom không được tính là phụ thuộc theo nghĩa này. Với 2 cái đầu tiên, bạn sẽ chỉ ghép chúng trong phạm vi thư viện của bạn và không lo lắng về sự trùng lặp có thể xảy ra. Ví dụ, jQuery kết hợp một isArrayLikehàm bên trong , mặc dù người dùng có thể đã có riêng của mình từ một thư viện vành đai tiện ích ngẫu nhiên.

Tôi chỉ có một kinh nghiệm cá nhân với sự phụ thuộc rất lớn khi phát triển thư viện (thực ra là ngôn ngữ) - moment.js. Trong trường hợp này, tôi sẽ cung cấp 2 bản dựng, một bản dựng được ghép nối và một bản không có, trong đó người dùng chịu trách nhiệm bao gồm nó. Tôi không biết nếu đây là một giải pháp tốt.

Và vâng, trong mọi trường hợp, cách tiếp cận jQuery trong việc xây dựng một tệp lớn cuối cùng chỉ hoạt động được thực hiện. Nó có mô-đun soạn sẵn ở phía dưới (yêu cầu phát hiện / AMD / toàn cầu, v.v.).

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.