Làm cách nào để tôi quyết định liệu @ type / * đi vào `phụ thuộc` hay` devDependencies`?

194

Tôi sử dụng TypeScript 2 trong dự án của mình. Tôi muốn sử dụng một số thư viện js, nhưng cũng đánh máy cho thư viện đó. Tôi có thể cài đặt các loại với đơn giản npm install @types/some-library. Tôi không chắc là tôi nên --savehay --save-devhọ. Dường như với tôi rằng ngay cả DefinetelyTyped GitHub cũng đọc loại đề cập đến cả hai phiên bản, nhưng không bao giờ giải thích chúng. Tôi sẽ nghĩ rằng @types nên có devDependencies, vì các loại là cần thiết cho sự phát triển và không được sử dụng trong thời gian chạy, nhưng tôi đã thấy nhiều lần @types chỉ dependencies. Tôi bối rối.

Làm cách nào để quyết định xem @ type / * đi vào dependencieshay devDependencies? Có thực sự có một số hướng dẫn chính thức nhiều hay ít?

— kamyl
nguồn

Bạn đang tạo một gói hay đây là một gói sẽ được sử dụng bởi những người khác? Như tôi thấy, bạn chỉ cần phân biệt giữa dependenciesvà devDependenciestrong trường hợp sau.

— Valentin ngày

Tôi làm một số trò chơi trong js / ts từ đầu. Tôi gói mọi thứ với webpack. Không có phần phụ trợ nào cả, nhưng có thể tôi sẽ bọc tất cả trong Electron để làm cho nó độc lập một ngày nào đó. Tôi không nghĩ ai sẽ sử dụng nó như một sự phụ thuộc trong ứng dụng của riêng họ, nhưng tôi đoán điều đó là có thể (nghĩ về các trò chơi nhỏ trong các trò chơi GTA; và trò chơi của tôi là nguồn mở). Tuy nhiên, tôi muốn tìm hiểu và làm theo các thực tiễn tốt nhất và đó là lý do chính khiến tôi thực hiện trò chơi đó. Tôi hy vọng tôi đã làm rõ trường hợp sử dụng của tôi đủ tốt. :)

— kamyl

Vâng, nó có ý nghĩa, chỉ muốn đảm bảo rằng câu trả lời ban đầu của tôi có liên quan đến trường hợp sử dụng của bạn. Tôi vẫn nghĩ rằng sự khác biệt giữa devDependenciesvà dependencieslà không thích hợp khi xây dựng một bó, nó cái gì đó create-react-appthực thi cũng nhưng cuối cùng đó là tùy thuộc vào bạn để lựa chọn

— Valentin

Câu trả lời:

131

Giả sử bạn đang phát triển gói "A" có gói @ type / some-module trong devDependencies. Vì một số lý do, bạn đang xuất loại từ @ type / some-module

import {SomeType} from 'some-module';
export default class APackageClass {
     constructor(private config: SomeType) {

     }
}

Ngay bây giờ, người tiêu dùng bản in của gói "A" không thể đoán được một số loại là gì, vì devDepencies của gói "A" KHÔNG được cài đặt.

Trong trường hợp cụ thể đó, bạn CẦN đặt gói @ type / * với "phụ thuộc" thông thường. Đối với các trường hợp khác, "devDependencies" là đủ tốt.

— wookieb
nguồn

Vì vậy, bạn ngụ ý rằng, nếu tôi chỉ sử dụng loại trong triển khai, định nghĩa loại đó có thể là devDependenciesgì?

— Franklin Yu

Có @FranklinYu. Ngay khi loại xuất hiện trong tệp khai báo, bạn cần đặt nó vào dependencies. Nếu không thì devDependenciesvẫn ổn

— wookieb

Nhưng một gói hoạt động cho cả TS và JS. Các nhà phát triển JS không cần các kiểu đó để biên dịch mã của họ. Thêm định nghĩa kiểu dependenciessẽ làm cho cây phụ thuộc nở hoa.

— Tyler Long

@TylerLong Đúng. Nó không hoàn hảo nhưng đó là thực tế. Tùy chọn Bạn cũng có thể sử dụng "tùy chọn phụ thuộc" nhưng tôi tin ở quy mô có thể rất khó chịu.

— wookieb

Nếu bạn chỉ tạo một gói, có thể không cần phân biệt giữa dependenciesvà devDependencies. Tính năng npmnày thường hữu ích khi xuất bản một gói có thể được người khác sử dụng và bạn không muốn spam chúng với các phụ thuộc dư thừa.

Có thể có các trường hợp sử dụng khác trong đó việc chia nhỏ các phụ thuộc có thể hữu ích nhưng trừ khi bạn có nhu cầu rõ ràng về vấn đề này, thì lời khuyên của tôi là chỉ cần chọn một trong hai và đặt mọi thứ ở đó. Không khó để phân chia chúng sau đó nếu cần.

Một ví dụ nổi tiếng của thực hành IRL này là create-react-app, theo mặc định, nồi hơi không được đẩy ra, nó tạo ra mọi thứ trong đó dependencies, xem chủ đề này và câu trả lời này

— Valentin
nguồn

Nếu bạn không xuất bản gói, điều đó đúng, nhưng nếu bạn là vậy, thì nó không liên quan gì đến phát triển so với thời gian chạy và mọi thứ cần thiết để xây dựng gói này so với những gì cần thiết để sử dụng gói này .

— Yogu

@Yogu Đó là lý do tại sao tôi tạo ra sự khác biệt ngay từ đầu nên vâng, tôi hoàn toàn đồng ý với bạn

— Valentin ngày

Tôi không đồng ý với lời khuyên này. devDependencieskhông được cài đặt khi bạn làm npm install --production(hoặc npm ci --production) và do đó không khả dụng khi chạy mã sản xuất. Đây là một sự khác biệt rất có ý nghĩa đối với một dịch vụ, không chỉ là một thư viện.

— Brad Wilson

@BradWilson Bạn có một điểm, có nhiều luồng công việc npm dưới ánh mặt trời, nếu trường hợp sử dụng của bạn yêu cầu bạn phải phân biệt thì bằng mọi cách, hãy làm điều đó. Hãy cung cấp câu trả lời của riêng bạn cho vấn đề nan giải này.

— Valentin ngày

Tôi đã cập nhật câu trả lời của mình để đề cập đến sự tồn tại của các trường hợp sử dụng khác trong đó sự khác biệt có thể có ý nghĩa và đưa ra các ví dụ thực tế. Cảm ơn vì bạn đã phản hồi!

— Valentin

Trong trường hợp cụ thể triển khai ứng dụng Node.js vào sản xuất, người ta chỉ muốn cài đặt các phụ thuộc cần thiết để chạy ứng dụng.

npm install --production hoặc là

npm ci --production hoặc là

yarn --production

Trong trường hợp đó, các loại nên ở trong devDependencies, để giữ cho chúng không bị đầy hơi khi cài đặt.

Lưu ý: Tôi biết điều này đã được đề cập trong một bình luận của Brad Wilson cho một câu trả lời khác. Điểm này có vẻ xứng đáng là một câu trả lời, mặc dù.

— Carsten Führmann
nguồn