Nhiều nhà phát triển bỏ qua nhà soạn nhạc. khóa vào của họ. gitignore, vì đây là tệp được tạo tự động. Bằng cách phân tích các. Tuy nhiên, mục đích của gitignore lý thuyết này là đúng, tuy nhiên, là một cách thực hành tốt để quản lý kiểm soát phiên bản của tệp này và sử dụng lệnh cài đặt của trình soạn thảo để chuẩn bị môi trường. Tránh cập nhật nhà soạn nhạc, hãy kiểm tra cơ sở duy trì ý tưởng đó để áp dụng thay đổi này cho các dự án của bạn
– Bạn có thể tìm thấy trong câu nói
“Bạn nên cam kết nhà soạn nhạc. lock vào repo dự án của bạn để tất cả những người làm việc trong dự án đều bị khóa với cùng một phiên bản phụ thuộc. ”
– Có tệp khóa, sẽ trở thành quá trình cài đặt phụ thuộc nhanh hơn gấp 2 lần
– Bạn có thể để nó tối ưu hơn bằng cách sử dụng các tham số để tối ưu hóa autoload. Ưu tiên các gói thông qua nguồn và tránh nhận các phần phụ thuộc của nhà phát triển trong quá trình sản xuất
– Vì mỗi lần cài đặt sẽ sử dụng tệp khóa, nó sẽ cài đặt cùng một phiên bản phân phối gói cho mỗi nhà phát triển. Tránh câu nổi tiếng “Nó đang hoạt động trong máy của tôi”
– Thực hành này không được khuyến nghị cho các thư viện theo
“Đối với thư viện của bạn, bạn có thể cam kết trình soạn thảo. khóa tập tin nếu bạn muốn. ”
– Không bao giờ sử dụng cập nhật nhà soạn nhạc trong sản xuất. Nó có thể cập nhật các gói mà bạn chưa cập nhật trong dàn dựng, môi trường dàn dựng có thể mất mục đích của nó
Bạn có đang tạo phiên bản cho tệp khóa của mình không? . Nếu bạn cần tư vấn cho công ty hoặc dự án của mình, hãy cho tôi biết tại đây
Tìm kiếm
Về tôi
Rafael Corrêa Gomes
Kiến trúc sư và nhà phát triển thương mại điện tử cấp cao có trụ sở tại Montreal, Canada. Hơn mười năm kinh nghiệm phát triển thương mại điện tử, sản phẩm saas và quản lý nhóm làm việc với Magento, Shopify, PHP, JavaScript và NodeJS
Khi làm việc với nhiều nhà phát triển trong một dự án, rất nhiều điều có thể xảy ra liên quan đến các phụ thuộc của Trình soạn thảo. Các gói được thêm, xóa và nâng cấp. Đôi khi một gói đã được thêm vào, các phần phụ thuộc khác cũng có thể cần nâng cấp. Hoặc một nhà phát triển vô tình nâng cấp tất cả các gói vì họ sử dụng lệnh sai. [luôn chạy “cập nhật nhà soạn nhạc” rõ ràng là một thói quen khó bỏ]
Mặc dù nhà soạn nhạc. lock chỉ tồn tại để khóa các phần phụ thuộc vào bản phát hành của các phần phụ thuộc mà bạn biết chắc chắn kết hợp với bản phát hành có thể cài đặt và bạn có thể không theo dõi sát sao, bộ gói ổn định đó là điều quan trọng cần theo dõi. Các nhà phát triển mắc lỗi và các nhà phát triển gói cũng vậy. Vì vậy, khi một gói được cập nhật từ x. y. 1 đến x. y. 2, một cái gì đó có thể vô tình phá vỡ. Nhưng khi mỗi lần bạn nhìn vào tệp khóa để kiểm tra những gì thực sự đã thay đổi, mỗi dòng được tô sáng, bạn có thể có xu hướng chỉ chấp nhận yêu cầu kéo hoặc hợp nhất đó
Nguyên nhân gốc rễ của những thay đổi dường như 'ngẫu nhiên' này đối với tệp khóa là do các nhà phát triển khác nhau làm việc với các phiên bản soạn thảo khác nhau. Nhà soạn nhạc 1. 0. 0 hiện đã tròn 5 tuổi và rất nhiều thứ đã thay đổi kể từ đó. Các thuật toán băm đã thay đổi và các phần đã được xóa và thêm vào. Nhưng không phải tất cả các nhà phát triển đều nâng cấp các gói và trình quản lý gói của họ
Tôi đã cố gắng tạo danh sách tất cả các thay đổi giữa các phiên bản bằng cách chạy lệnh “nhà soạn nhạc không có gì” trên mọi phiên bản nhà soạn nhạc nhỏ, nhưng nhanh chóng được nhắc nhở rằng không có cách nào dễ dàng để chuyển đổi giữa phiên bản Nhà soạn nhạc ban đầu và “bản tự cập nhật của nhà soạn nhạc” . Thay vào đó, tôi đã tạo một tệp khóa trên Composer 1. 0. 0 và trên phiên bản mới nhất của Composer - 2. 0. 12 - và so sánh tệp khóa. Mặc dù không theo dõi chính xác tất cả các thay đổi và không hiển thị phiên bản nào thay đổi những gì, nhưng nó mang lại một cái nhìn tổng quan thú vị
- Url của phần readme đã thay đổi giữa và trong tệp khóa
- Phần “hash” được đổi tên thành “content-hash” hoặc ngược lại trong tệp khóa
- "Băm" hoặc "băm nội dung" đã được tính toán lại ngay cả khi phần còn lại của nhà soạn nhạc. khóa không thay đổi
- Phần “hỗ trợ” đã được thêm hoặc xóa với các gói riêng lẻ trong tệp khóa
- Phần “thời gian” hiện đã thêm hoặc xóa “T” và phần bù múi giờ biểu thị dấu thời gian được bản địa hóa với các gói riêng lẻ trong tệp khóa
- Phần "cấp vốn" đã được thêm hoặc xóa với các gói riêng lẻ trong tệp khóa
- Phần "plugin-api-version" đã được thêm hoặc xóa vào trình soạn nhạc. tập tin khóa
vui lòng mở PR để thêm bất kỳ thay đổi nào còn thiếu
Tất cả những vấn đề này và nhiều vấn đề khác là chỉ báo của các nhà phát triển khác nhau đang chạy lệnh cập nhật tệp khóa như “nhà soạn nhạc yêu cầu nhà cung cấp/tên gói” hoặc “cập nhật nhà soạn nhạc [không có gì]” trên các phiên bản Trình soạn thảo khác với nhà phát triển trước đó
Trước đây, không có cách nào dễ dàng để buộc tất cả các nhà phát triển sử dụng cùng một phiên bản Trình soạn thảo khi tất cả họ đều có máy [ảo] riêng ngoài việc quản lý các máy đó rất chặt chẽ. Hầu hết các nhà phát triển không hài lòng khi họ không có toàn quyền kiểm soát hệ điều hành của họ và bạn cập nhật cấu hình và các gói đã cài đặt của họ
May mắn thay, có một giải pháp mà tôi đang nghiên cứu gần đây. Thay vì trực tiếp quản lý việc cài đặt Trình soạn thảo, tôi đã phát triển một gói yêu cầu một phiên bản Trình soạn thảo nhất định khi nhà phát triển muốn chạy một lệnh cho gói đó để sửa đổi tệp khóa. Bên cạnh việc thêm một ràng buộc về phiên bản, bạn cũng có thể đề xuất một phiên bản cụ thể [không có lỗi/ổn định]
Để bắt đầu, hãy chạy
composer require prinsfrank/composer-version-lock
và
composer config extra.composer-version {VERSION_CONSTRAINT}
để bạn có thể yêu cầu tất cả các nhà phát triển đồng nghiệp của mình đang làm việc trong một dự án sử dụng một phiên bản Trình soạn thảo cụ thể khi họ muốn cập nhật tệp khóa. Đọc thêm về repo Github