Làm cách nào để tích hợp nhiều tính năng của các ứng dụng khác, các ứng dụng có thể phản ứng vào các repo PHP nguyên khối?

Chúng tôi có một mono-laravel-repo và đang trong quá trình chuyển sang một trình dọn dẹp dev dễ dàng hơn, dễ dàng hơn để duy trì dev.

Gần đây chúng tôi đã chuyển sang hướng di chuyển các khung nhìn dựa trên PHP hiện có của chúng tôi vào nhiều "tính năng" dựa trên React sống trong một /reactthư mục và được tổ chức thành /react/featureNamecác thư mục con. Điều này có nghĩa là bộ điều khiển của Laravel chủ yếu chỉ xử lý dữ liệu và xác thực.

Mỗi tính năng được duy trì bởi một hoặc nhiều nhà phát triển, có các phụ thuộc, kiểm tra và chức năng riêng.

Chúng tôi hiện đang phục vụ các bản dựng trong gốc công khai của dự án của chúng tôi được tổ chức theo tính năng:

js/FeatureName.hashed.js
css/FeatureName.hased.css

hoạt động tuyệt vời ngoại trừ việc chúng tôi chia sẻ nhiều gói giữa features. Phản ứng chính nó, phản ứng-bộ định tuyến, vv

Chúng tôi dự định sử dụng mix.jscàng nhiều càng tốt, nhưng hack trực tiếp webpack.configcũng là một lựa chọn.

Tôi đã khám phá các mix.extract()tùy chọn cho phép chúng ta xác định vendor.js xây dựng tách biệt với logic ứng dụng khác, nhưng nó dừng lại ở đó.

Vì vậy, đây là những câu hỏi của tôi)

1. Có những cách tiếp cận nào để quản lý nhiều package.jsontệp sống trong mỗi thư mục tính năng
2. Làm thế nào để chúng tôi xác định các gói phổ biến và khóa chúng vào một /package.jsontập tin gốc . (Độc lập, tất cả các nhà phát triển đã sử dụng yarn)
3. Làm thế nào để thực hiện điều này với ít ma sát nhất có thể cho tất cả các nhà phát triển dựa trên phản ứng - để họ có thể tiếp tục đơn giản với bất cứ điều gì họ đang làm và DevOps xử lý các bit gritty?

Tôi hiểu có thể cần thêm thông tin, vui lòng nói ra những gì bạn cần trong các bình luận và tôi rất vui lòng cập nhật câu hỏi.

1. Có những cách tiếp cận nào để quản lý nhiều tệp pack.json sống trong mỗi thư mục tính năng

Người ta có thể để lại pack.json trong mọi thư mục tính năng và để CI đọc gói.json khi xây dựng ứng dụng. Người ta có thể định nghĩa các phiên bản phụ thuộc trong gói.json để kiểm soát ứng dụng. Nếu ứng dụng hoạt động với phiên bản ABC của một thư viện nhất định thì người ta có thể xác định phiên bản này để ngăn chặn việc cập nhật sẽ phá vỡ ứng dụng.

2. Làm cách nào để xác định các gói phổ biến và khóa chúng vào tệp gốc /package.json. (Độc lập, tất cả các nhà phát triển đã sử dụng sợi)

Thảo luận về vấn đề này với nhóm và tìm ra đâu là giải pháp tốt nhất cho mọi người. Nhiều giải pháp là có thể. Mọi người nên hạnh phúc với một cách tiếp cận nhất định.

3. Làm thế nào để thực hiện điều này với ít ma sát nhất có thể cho tất cả các nhà phát triển dựa trên phản ứng - để họ có thể tiếp tục đơn giản với bất cứ điều gì họ đang làm và DevOps xử lý các bit gritty?

Theo ý kiến ​​của tôi, DevOps có nghĩa là một nhóm nhất định bao gồm nhiều chuyên ngành, ví dụ: test, dev, ops chịu trách nhiệm cho một ứng dụng nhất định. Điều này có nghĩa là toàn bộ nhóm nên đồng ý với một cách tiếp cận nhất định và mọi người nên làm việc và xử lý các vấn đề theo quy trình đó thay vì DevOps handles the gritty bitsđó là về silo và "ném nó lên tường"