Tôi có cam kết tệp gói-lock.json được tạo bởi npm 5 không?


1395

npm 5 đã được phát hành hôm nay và một trong những tính năng mới bao gồm cài đặt xác định với việc tạo package-lock.jsontệp.

Là tập tin này được cho là được giữ trong kiểm soát nguồn?

Tôi cho rằng nó tương tự yarn.lockcomposer.lock, cả hai đều được cho là được kiểm soát nguồn.


20
Câu trả lời ngắn gọn: có. Một nhận xét: khi gói-lock.json thay đổi, bạn có thể thực hiện cam kết chỉ thay đổi đó, tách biệt với các thay đổi nguồn khác. Điều này làm cho git logdễ đối phó hơn.
Áo tím

14
Một tập tin không thể giúp tạo ra một cài đặt xác định nếu nó không tồn tại.
Alan H.

4
Phụ thuộc vào dự án. github.com/npm/npm/issues/20603
Gajus

3
Nếu bạn thực sự tin tưởng npm chắc chắn, mục đích là để báo cáo rõ ràng hơn những gì dự án đang sử dụng. Nếu bạn thực sự muốn dự đoán, hãy bỏ qua tệp này và thay vào đó cài đặt node_modules của bạn (xem .npmrc và cấu hình có liên quan trong câu trả lời + nhận xét) và sử dụng tệp đó để theo dõi những gì thực sự thay đổi thay vì trình quản lý gói của bạn nói. Rốt cuộc: wich quan trọng hơn? Trình quản lý gói của bạn hoặc mã bạn đang sử dụng.
jimmont

Câu trả lời:


1616

Có, package-lock.jsondự định sẽ được kiểm tra vào kiểm soát nguồn. Nếu bạn đang sử dụng npm 5, bạn có thể thấy điều này trên dòng lệnh: created a lockfile as package-lock.json. You should commit this file.Theo npm help package-lock.json:

package-lock.jsonđược tạo tự động cho bất kỳ hoạt động nào trong đó npm sửa đổi node_modulescây hoặc package.json. Nó mô tả cây chính xác đã được tạo, sao cho các lần cài đặt tiếp theo có thể tạo các cây giống hệt nhau, bất kể cập nhật phụ thuộc trung gian.

Tập tin này được dự định cam kết vào kho lưu trữ nguồn và phục vụ các mục đích khác nhau:

  • Mô tả một đại diện duy nhất của cây phụ thuộc sao cho đồng đội, triển khai và tích hợp liên tục được đảm bảo để cài đặt chính xác các phụ thuộc giống nhau.

  • Cung cấp một phương tiện để người dùng "du hành thời gian" đến các trạng thái trước đó node_modulesmà không phải cam kết thư mục đó.

  • Để tạo điều kiện cho tầm nhìn thay đổi cây lớn hơn thông qua các điều khiển nguồn khác nhau có thể đọc được.

  • Và tối ưu hóa quá trình cài đặt bằng cách cho phép npm bỏ qua các độ phân giải siêu dữ liệu lặp lại cho các gói được cài đặt trước đó.

Một chi tiết quan trọng package-lock.jsonlà nó không thể được công bố và nó sẽ bị bỏ qua nếu được tìm thấy ở bất kỳ nơi nào khác ngoài gói toplevel. Nó chia sẻ một định dạng với npm-shrwrap.json (5), về cơ bản là cùng một tệp, nhưng cho phép xuất bản. Điều này không được khuyến khích trừ khi triển khai một công cụ CLI hoặc sử dụng quy trình xuất bản để sản xuất các gói sản xuất.

Nếu cả hai package-lock.jsonnpm-shrinkwrap.jsonhiện diện trong thư mục gốc của gói, package-lock.jsonsẽ bị bỏ qua hoàn toàn.


77
Trong các loại dự án thực sự hữu ích để cam kết các tập tin? Điểm chung của semver và pack.json là các phụ thuộc tương thích được cập nhật không cần phải lưu ý.
tò mò

45
Từ khóa là "không cần phải như vậy" - nhưng trong thực tế mọi người không theo dõi hoàn hảo. Đó là lý do tại sao bạn có thể sử dụng gói-lock.json và pack.json để dễ dàng cập nhật các gói nhưng vẫn đảm bảo mọi nhà phát triển và mọi ứng dụng được triển khai đều sử dụng cùng một cây phụ thuộc.
Panu Horsmalahti

34
@trusktr: Sindre Sorhus khuyên bạn nên sử dụng "Lockfiles cho các ứng dụng, nhưng không phải cho các gói."
Vine77

23
Một điều nữa là, gói-lock.json bị bỏ qua để xuất bản trên NPM, vì vậy nếu nhà phát triển sử dụng nó cho nhà phát triển thư viện, thì họ sẽ giảm thiểu khả năng họ sẽ bắt được hồi quy từ phiên bản phụ thuộc được cập nhật và do đó sẽ vượt qua điều đó lỗi vào người dùng cuối. Vì lý do này, việc không sử dụng tệp khóa cho nhà phát triển thư viện sẽ làm tăng cơ hội vận chuyển ít lỗi hơn.
trusktr

128
Cá nhân tôi giờ đã phải dùng đến việc thêm package-lock.jsonvào .gitignore... điều này khiến tôi gặp nhiều vấn đề hơn là giải quyết chúng. Nó luôn xung đột khi chúng ta hợp nhất hoặc khởi động lại và khi hợp nhất dẫn đến package-lock.jsonviệc bị hỏng trên máy chủ CI, thật khó khăn khi phải sửa nó.
Stefan Z Camilleri

111

Có, nó dự định được kiểm tra. Tôi muốn đề xuất rằng nó có được cam kết duy nhất của riêng mình. Chúng tôi thấy rằng nó thêm rất nhiều tiếng ồn cho khác biệt của chúng tôi.


19
thật công bằng khi tranh luận liệu nó có nên được kiểm tra vào kho lưu trữ mã nguồn của bạn hay không, nhưng việc xuất bản tệp này lên npm không thực sự gây tranh cãi - bạn phải đưa gói-lock.json hoặc tệp thu nhỏ của mình vào sổ đăng ký npm. nếu bạn không làm như vậy, gói được xuất bản của bạn sẽ chịu sự thay đổi không được xem xét của các phụ thuộc của các phụ thuộc thế hệ 1 của bạn. bạn sẽ không nhận thấy đây là một vấn đề cho đến khi một trong những phụ thuộc thế hệ 2 + đó xuất bản một thay đổi đột phá và gói được xuất bản của bạn bị phá vỡ một cách bí ẩn. tệp gói-lock.json này đã được tạo để giải quyết vấn đề đó.
guerillapresident

9
@BetoAveiga bởi tiếng ồn Tôi có nghĩa là các cam kết với gói-lock.json có thể có rất nhiều dòng phiên bản gói nút, mà bất kỳ công việc nào khác trong cam kết đó đều bị ẩn.
xer0x

7
Tôi thường giữ cài đặt gói riêng biệt với công việc khác. Tôi không bao giờ cần phải thực hiện một cam kết như "Đã cài đặt chai và mocha", vì tôi đã biết những gì đã thay đổi.
Keith

3
Bạn có lời khuyên nào về package-lock.jsontập tin khi làm việc trên hệ thống SCM với các thân cây và phân nhánh không? Tôi đang thực hiện một số thay đổi trên một nhánh cần được hợp nhất vào thân cây ... bây giờ tôi có phải (bằng cách nào đó) giải quyết xung đột giữa hai package-lock.jsontệp không? Điều này cảm thấy đau đớn.
kmiklas

3
@guerillapresident Theo tôi hiểu, bạn đã đúng một phần. Xuất bản tập tin này đến npm không phải là tranh luận. Bạn không thể xuất bản nó.
Tim Gautier

66

Có, bạn NÊN:

  1. cam kết package-lock.json.
  2. sử dụng npm cithay vìnpm install khi xây dựng các ứng dụng của bạn cả trên CI và máy phát triển cục bộ của bạn

Quy npm citrình công việc đòi hỏi sự tồn tại của a package-lock.json.


Một nhược điểm lớn của npm installlệnh là hành vi không mong muốn của nó có thể làm thay đổi package-lock.json, trong khi npm cichỉ sử dụng các phiên bản được chỉ định trong tệp khóa và tạo ra lỗi

  • nếu package-lock.jsonpackage.jsonkhông đồng bộ
  • nếu a package-lock.jsonbị thiếu

Do đó, chạy npm installcục bộ, đặc biệt. trong các nhóm lớn hơn có nhiều nhà phát triển, có thể dẫn đến nhiều xung đột trong package-lock.jsonvà các nhà phát triển quyết định xóa hoàn toàn package-lock.jsonthay thế.

Tuy nhiên, có một trường hợp sử dụng mạnh mẽ để có thể tin tưởng rằng các phụ thuộc của dự án giải quyết lặp lại theo cách đáng tin cậy trên các máy khác nhau.

Từ một package-lock.jsonbạn nhận được chính xác rằng: một trạng thái làm việc được biết đến.

Trước đây, tôi có các dự án không có package-lock.json/ npm-shrinkwrap.json/ yarn.locktệp mà quá trình xây dựng sẽ thất bại một ngày vì một phụ thuộc ngẫu nhiên có một bản cập nhật phá vỡ.

Những vấn đề đó rất khó giải quyết vì đôi khi bạn phải đoán phiên bản làm việc cuối cùng là gì.

Nếu bạn muốn thêm một phụ thuộc mới, bạn vẫn chạy npm install {dependency}. Nếu bạn muốn nâng cấp, hãy sử dụng npm update {dependency}hoặc npm install ${dependendency}@{version}và cam kết thay đổi package-lock.json.

Nếu nâng cấp thất bại, bạn có thể trở lại hoạt động đã biết cuối cùng package-lock.json.


Để trích dẫn tài liệu npm :

Rất khuyến khích bạn cam kết khóa gói được tạo để kiểm soát nguồn: điều này sẽ cho phép bất kỳ ai khác trong nhóm của bạn, triển khai, tích hợp liên tục / CI của bạn và bất kỳ ai khác chạy cài đặt npm trong nguồn gói của bạn để có được cây phụ thuộc chính xác như nhau mà bạn đang phát triển Ngoài ra, các khác biệt từ những thay đổi này đều có thể đọc được và sẽ thông báo cho bạn về bất kỳ thay đổi nào mà npm đã thực hiện đối với node_modules của bạn, vì vậy bạn có thể nhận thấy nếu có bất kỳ phụ thuộc bắc cầu nào được cập nhật, nâng lên, v.v.

Và liên quan đến sự khác biệt giữa npm civsnpm install :

  • Dự án phải có gói-lock.json hoặc npm-shrwrap.json hiện có.
  • Nếu các phụ thuộc trong khóa gói không khớp với các gói trong gói.json, npm cisẽ thoát với một lỗi, thay vì cập nhật khóa gói.
  • npm ci chỉ có thể cài đặt toàn bộ dự án tại một thời điểm: không thể thêm các phụ thuộc riêng lẻ bằng lệnh này.
  • Nếu một node_modulesđã có sẵn, nó sẽ tự động bị xóa trước khi npm cibắt đầu cài đặt.
  • Nó sẽ không bao giờ ghi vào package.jsonhoặc bất kỳ khóa nào: các bản cài đặt về cơ bản bị đóng băng.

Lưu ý: Tôi đã đăng một câu trả lời tương tự ở đây


10
Câu trả lời này xứng đáng nhận được nhiều tín dụng hơn, đặc biệt là sử dụng npm ci. Sử dụng điều này giảm thiểu hầu hết các vấn đề mọi người gặp phải với khóa gói.
JamesB

Tôi đã thấy sử dụng phiên bản cố định trong pack.json (không có dấu mũ hoặc dấu ngã) là một tùy chọn sạch hơn nhiều. Điều này cứu tôi khỏi whose build would fail one day because a random dependency got a breaking updateloại vấn đề. Mặc dù nó để lại khả năng phụ thuộc của trẻ em có cùng một vấn đề.
Ashwani Agarwal

58

Có, cách thực hành tốt nhất là đăng ký (CÓ, KIỂM TRA)

Tôi đồng ý rằng nó sẽ gây ra nhiều tiếng ồn hoặc xung đột khi nhìn thấy khác biệt. Nhưng lợi ích là:

  1. đảm bảo chính xác cùng một phiên bản của mỗi gói . Phần này là quan trọng nhất khi xây dựng trong các môi trường khác nhau tại các thời điểm khác nhau. Bạn có thể sử dụng ^1.2.3trong của mình package.json, nhưng làm thế nào bạn có thể đảm bảo mỗi lần npm installsẽ nhận được cùng một phiên bản trong máy dev của bạn và trong máy chủ xây dựng, đặc biệt là các gói phụ thuộc gián tiếp? Vâng, package-lock.jsonsẽ đảm bảo rằng. (Với sự giúp đỡ trong npm ciđó cài đặt các gói dựa trên tệp khóa)
  2. nó cải thiện quá trình cài đặt.
  3. nó giúp với tính năng kiểm toán mới npm audit fix(tôi nghĩ rằng tính năng kiểm toán là từ npm phiên bản 6).

3
Theo như tôi biết, không bao giờ sử dụng semver (điều mà các nhà phát triển npm không hiểu gì) sẽ mang lại hành vi tương tự như có một lockfile ít nhất trong 99% trường hợp. Kinh nghiệm của bản thân tôi là các cuộc tấn công giữa chừng xảy ra chủ yếu với các gói chính (phụ thuộc trực tiếp, công cụ hẹn hò jquery nhảm nhí, v.v.). Trải nghiệm cá nhân của tôi với npm là các tệp khóa bị nhiễu mãi mãi. Tôi hy vọng sự khôn ngoan này là không thay đổi với các phiên bản gần đây.
Svend

13
+1 để đề cập npm ci. Mọi người thường đề cập rằng việc package-lock.jsoncho phép cài đặt các gói xác định nhưng hầu như không bao giờ đề cập đến lệnh tạo điều kiện cho hành vi này! Nhiều người có thể giả định không chính xác npm installcài đặt chính xác những gì trong tệp khóa ...
ahaurat

npm ci không ở npm 5.
dpurrington

Cảm ơn bạn! Nó chỉ có ý nghĩa để cam kết gói-lock.json nếu bạn đang sử dụng npm ci. Nhóm / nhà phát triển chính của bạn có thể quyết định khi nào cần cập nhật. Nếu mọi người chỉ tự ý cam kết, thì không có lý do gì, và nó chỉ tạo ra tiếng ồn trong repo của bạn. Tài liệu NPM nên làm cho điều này rõ ràng hơn. Tôi nghĩ rằng hầu hết các nhà phát triển chỉ bị nhầm lẫn bởi tính năng này.
adampasz

@adampasz thực sự mỗi nhà phát triển có thể cam kết tệp khóa và một khi vượt qua thử nghiệm và sáp nhập, nhánh thứ hai chỉ cần gia hạn tệp khóa nếu bằng cách nào đó các gói bị thay đổi (chúng tôi không thay đổi gói.json thường xuyên, chúng tôi sẽ ít gặp phải vấn đề này hơn (
Xin chào

38

Tôi không cam kết tập tin này trong các dự án của tôi. Vấn đề ở đây là gì ?

  1. Nó được tạo ra
  2. Đó là nguyên nhân gây ra lỗi toàn vẹn mã SHA1 trong gitlab với các bản dựng gitlab-ci.yml

Mặc dù đúng là tôi không bao giờ sử dụng ^ trong gói.json của mình cho lib vì tôi có trải nghiệm xấu với nó.


11
Tôi ước điều này có thể được giải thích nhiều hơn từ trong các tài liệu npm - Sẽ rất hữu ích khi có một phác thảo về những gì cụ thể bạn mất bằng cách không cam kết package-lock.json. Một số repos có thể không yêu cầu lợi ích đến từ việc có nó và có thể không có nội dung được tạo tự động trong nguồn.
PotatoFarmer

2
Tôi có thể thấy làm thế nào nó có thể hữu ích cho việc gỡ lỗi (ví dụ khác biệt giữa hai khóa) để giúp giải quyết vấn đề. Tôi đoán nó cũng có thể được sử dụng để ngăn chặn những thứ này nhưng cũng có thể là một nỗi đau khi sử dụng nó trong một repo được chia sẻ, nơi nó có thể gặp xung đột hợp nhất do nó. Đối với người mới bắt đầu, tôi muốn giữ mọi thứ đơn giản, tôi sẽ chỉ sử dụng gói.j.j cho đến khi tôi thấy có nhu cầu thực sự đối với gói-lock.json.
radtek

6
Bạn có thể không sử dụng ^ tại gói.json của mình, nhưng bạn có thể chắc chắn rằng các phụ thuộc của bạn không sử dụng nó không?
neiker

35

Để mọi người phàn nàn về tiếng ồn khi làm git diff:

git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'

Những gì tôi đã làm là sử dụng một bí danh:

alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"

Để bỏ qua gói-lock.json trong diffs cho toàn bộ kho lưu trữ (mọi người sử dụng nó), bạn có thể thêm phần này vào .gitattributes:

package-lock.json binary
yarn.lock binary

Điều này sẽ dẫn đến các khác biệt hiển thị "Tệp nhị phân a / pack-lock.json và b / pack-lock.json khác nhau bất cứ khi nào tệp khóa gói được thay đổi. Ngoài ra, một số dịch vụ Git (đặc biệt là GitLab, nhưng không phải GitHub) cũng sẽ loại trừ các tệp này (không thay đổi thêm 10k dòng!) từ các khác biệt khi xem trực tuyến khi thực hiện việc này.


1
Tôi có gd() { git diff --color-words $1 $2 -- :!/yarn.lock :!/package-lock.json; }trong .bashrc của mình thay vì bí danh.
apostl3pol

16

Có, bạn có thể cam kết tập tin này. Từ các tài liệu chính thức của npm :

package-lock.jsonđược tạo tự động cho mọi hoạt động trong đó npmsửa đổi node_modulescây hoặc package.json. Nó mô tả cây chính xác đã được tạo, sao cho các lần cài đặt tiếp theo có thể tạo các cây giống hệt nhau, bất kể cập nhật phụ thuộc trung gian.

Tập tin này được dự định cam kết vào kho lưu trữ nguồn [.]


13
Không phải cài đặt luôn cập nhật node_modules và do đó cập nhật gói-lock.json?
Tim Gautier

2
Không, bạn có thể chạy npm ciđể cài đặt từ gói-lock.json
William Hampshire

Bạn cần nhấn mạnh trong câu trả lời của mình rằng bạn PHẢI sử dụng npm ci trong bản dựng tích hợp liên tục của bạn nếu bạn có gói-lock.json trên repo
MagicLAMP

6

Vô hiệu hóa gói-lock.json trên toàn cầu

gõ như sau trong thiết bị đầu cuối của bạn:

npm config set package-lock false

điều này thực sự hiệu quả với tôi như ma thuật


2
điều này tạo ra ~/.npmrc(ít nhất là trên macos của tôi) với nội dung package-lock=falsevà tương tự có thể được thực hiện trong bất kỳ dự án cụ thể bên cạnh node_modules/(ví dụecho 'package-lock=false' >> .npmrc
jimmont

6
thật buồn cười với tôi rằng đây sẽ là một điều tiêu cực. cộng đồng npm không thể chấp nhận rằng thế hệ tự động gói-lock.json là sự tham gia của cộng đồng xấu. bạn không nên làm những thứ có thể ảnh hưởng đến quá trình của một nhóm. nó nên là một tùy chọn để kích hoạt, không bị ép buộc. có bao nhiêu người chỉ làm "git add *" và thậm chí không nhận thấy điều đó và làm hỏng các bản dựng. Nếu bạn có bất kỳ loại luồng dựa trên hợp nhất nào, tôi biết luồng git giống như kinh thánh cho những người sử dụng nó, điều này sẽ không hoạt động. bạn không thể có thế hệ hợp nhất! Phiên bản npm bị hỏng, gói: 1.0.0 nên có tính quyết định!
Eric Twilegar

3
Tại sao điều này được bỏ phiếu xuống? đây rõ ràng là một cách hợp pháp để vô hiệu hóa một tính năng không hoạt động. Và mặc dù nó không trả lời câu hỏi, nhưng nó sẽ trả lời câu hỏi. tức là nó không còn cần trả lời. Đồng ý với tôi :)
Superole

Lý do tại sao nó bị hạ cấp là vì bạn chỉ đơn giản là vô hiệu hóa một tính năng.
Raza

5

Có, đó là một thông lệ tiêu chuẩn để cam kết gói-lock.json

Lý do chính để cam kết gói-lock.json là mọi người trong dự án đều ở trên cùng một phiên bản gói.

Ưu điểm: -

  • Nếu bạn tuân theo phiên bản nghiêm ngặt và không cho phép tự động cập nhật lên các phiên bản chính để tự cứu mình khỏi các thay đổi không tương thích ngược trong các gói của bên thứ ba, thì việc khóa gói sẽ giúp ích rất nhiều.
  • Nếu bạn cập nhật một gói cụ thể, nó sẽ được cập nhật trong gói-lock.json và mọi người sử dụng kho lưu trữ sẽ được cập nhật lên phiên bản cụ thể đó khi họ thực hiện các thay đổi của bạn.

Nhược điểm: -

  • Nó có thể làm cho các yêu cầu kéo của bạn trông xấu xí :) '

Chỉnh sửa: - cài đặt npm sẽ không đảm bảo rằng tất cả mọi người trong dự án đều ở trên cùng một phiên bản gói. npm ci sẽ giúp với điều này.


4
Nhược điểm sẽ biến mất nếu bạn sử dụng npm cithay vì npm install.
k0pernikus

2
Phạm vi leo lên một chút, nhưng đây là thông tin thêm về lời khuyên tuyệt vời đó từ @ k0pernikus .
ruffin

1
"Mọi người trong dự án sẽ ở trên cùng một phiên bản gói, tất cả những gì bạn phải làm là cài đặt npm" Không đúng, bạn cần sử dụng "npm ci" thay vào đó
reggaeg Ức

Cảm ơn, @reggaeg Ức. Cập nhật câu trả lời của tôi cho điều này.
Nikhil Mohadikar

2

Việc sử dụng npm của tôi là để tạo css / js rút gọn / xấu xí và tạo javascript cần thiết trong các trang được cung cấp bởi một ứng dụng django. Trong các ứng dụng của tôi, Javascript chạy trên trang để tạo hình động, đôi khi thực hiện các cuộc gọi ajax, hoạt động trong khung VUE và / hoặc làm việc với css. Nếu gói-lock.json có một số quyền kiểm soát ghi đè đối với gói trong.j.j, thì có thể cần có một phiên bản của tệp này. Theo kinh nghiệm của tôi, nó không ảnh hưởng đến những gì được cài đặt bởi cài đặt npm, hoặc nếu có, nó chưa ảnh hưởng xấu đến các ứng dụng tôi triển khai theo hiểu biết của mình. Tôi không sử dụng mongodb hoặc các ứng dụng như vậy thường là máy khách mỏng.

Tôi xóa gói-lock.json khỏi repo vì cài đặt npm tạo tệp này và cài đặt npm là một phần của quy trình triển khai trên mỗi máy chủ chạy ứng dụng. Kiểm soát phiên bản của nút và npm được thực hiện thủ công trên mỗi máy chủ, nhưng tôi cẩn thận rằng chúng giống nhau.

Khi npm installđược chạy trên máy chủ, nó sẽ thay đổi gói-lock.json và nếu có thay đổi đối với tệp được ghi lại bởi máy chủ trên máy chủ, lần triển khai tiếp theo sẽ KHÔNG cho phép bạn lấy các thay đổi mới từ nguồn gốc. Đó là bạn không thể triển khai vì kéo sẽ ghi đè lên các thay đổi đã được thực hiện đối với gói-lock.json.

Bạn thậm chí không thể ghi đè lên gói-lock.json được tạo cục bộ với nội dung trên repo (đặt lại bản gốc gốc cứng), vì npm sẽ phàn nàn khi bạn phát lệnh nếu gói-lock.json không phản ánh nội dung trong đó node_modules do cài đặt npm, do đó phá vỡ triển khai. Bây giờ nếu điều này chỉ ra rằng các phiên bản hơi khác nhau đã được cài đặt trong node_modules, một lần nữa điều đó chưa bao giờ gây ra sự cố cho tôi.

Nếu node_modules không có trong repo của bạn (và nó không nên), thì nên bỏ qua gói-lock.json.

Nếu tôi thiếu một cái gì đó, xin vui lòng sửa cho tôi trong các ý kiến, nhưng điểm mà phiên bản được lấy từ tệp này không có ý nghĩa. Tệp pack.json có số phiên bản trong đó và tôi giả sử tệp này là tệp được sử dụng để xây dựng các gói khi cài đặt npm xảy ra, vì khi tôi gỡ bỏ nó, cài đặt npm phàn nàn như sau:

jason@localhost:introcart_wagtail$ rm package.json
jason@localhost:introcart_wagtail$ npm install
npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

và quá trình xây dựng không thành công, tuy nhiên khi cài đặt node_modules hoặc áp dụng npm để xây dựng js / css, sẽ không có khiếu nại nào nếu tôi xóa gói-lock.json

jason@localhost:introcart_wagtail$ rm package-lock.json 
jason@localhost:introcart_wagtail$ npm run dev

> introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

 10% building 0/1 modules 1 active ...

Chỉ cần thêm, bây giờ tôi đã cam kết gói-lock.json của mình vào kho lưu trữ của mình và tôi đang sử dụng npm ci trên triển khai ansible của mình, tôi tin rằng hãy xóa node_modules và cài đặt mọi thứ trong gói-lock.json mà không cập nhật. Điều này cho phép anh chàng mặt trước của tôi nâng cấp công cụ javascript mà không cần can thiệp thủ công khi triển khai.
MagicLAMP
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.