Chọn và định cấu hình công cụ xây dựng dựa trên các phương pháp hay nhất.
Hôm nay, web.dev sẽ cho ra mắt một sáng kiến mới có tên là tooling.report. Đây là một trang web cung cấp cho nhà phát triển web thông tin tổng quan về các tính năng được hỗ trợ trên một số công cụ xây dựng phổ biến. Chúng tôi xây dựng trang web này để giúp bạn chọn công cụ xây dựng phù hợp cho dự án tiếp theo, quyết định xem việc di chuyển từ công cụ này sang công cụ khác có đáng hay không, hoặc tìm hiểu cách kết hợp các phương pháp hay nhất vào cấu hình công cụ và cơ sở mã của bạn. Các công cụ có các khía cạnh trọng tâm khác nhau và đáp ứng những nhu cầu khác nhau, nghĩa là việc lựa chọn và định cấu hình công cụ liên quan đến việc đánh đổi. Với tooling.report, chúng tôi mong muốn giải thích những đánh đổi này và ghi lại cách làm theo các phương pháp hay nhất cho một công cụ xây dựng cụ thể.
Nghe thú vị phải không? Hãy truy cập tooling.report để bắt đầu khám phá hoặc đọc tiếp để tìm hiểu thêm về lý do và cách chúng tôi phát triển trang web này.
Các công cụ xây dựng thường cản trở chúng ta
Tại GoogleChromeLabs, chúng tôi đã tạo các ứng dụng web như Squoosh và Proxx, cũng như các trang web như trang web cho Hội nghị Nhà phát triển Chrome 2019. Giống như với bất kỳ dự án phát triển web nào, chúng tôi thường bắt đầu bằng cách thảo luận về cơ sở hạ tầng của dự án, chẳng hạn như môi trường lưu trữ, khung và cách thiết lập công cụ xây dựng. Cơ sở hạ tầng đó được cập nhật khi dự án diễn ra: các trình bổ trợ mới được thêm vào để phù hợp với các khung hoặc kỹ thuật mà chúng tôi áp dụng, hoặc cách chúng tôi viết mã được thay đổi để các công cụ xây dựng của chúng tôi hiểu rõ hơn về những gì chúng tôi đang cố gắng đạt được. Trong suốt quá trình này, chúng tôi thường nhận thấy rằng các công cụ chúng tôi chọn sẽ lại vô hiệu hoá chúng tôi.
Nhóm của chúng tôi tập trung vào việc cung cấp trải nghiệm web tốt nhất cho người dùng. Điều này thường dẫn đến việc tinh chỉnh cách tập hợp và phân phối các tài sản giao diện người dùng. Ví dụ: nếu một tập lệnh luồng chính và tập lệnh trình chạy web có các phần phụ thuộc dùng chung, chúng ta muốn tải các phần phụ thuộc này xuống một lần thay vì nhóm hai lần cho mỗi tập lệnh. Một số công cụ hỗ trợ ngay từ đầu, một số công cụ cần nỗ lực tuỳ chỉnh đáng kể để thay đổi hành vi mặc định, và đối với một số công cụ khác thì điều này hoàn toàn không thể.
Trải nghiệm này khiến chúng tôi tìm hiểu xem các công cụ xây dựng khác nhau có thể và không thể làm gì. Chúng tôi hy vọng sẽ tạo ra một danh sách kiểm tra về các tính năng để lần tiếp theo khi bắt đầu dự án mới, chúng tôi có thể đánh giá và chọn ra công cụ phù hợp nhất với dự án của mình.
Cách làm của chúng tôi
Làm cách nào để chúng tôi đánh giá và so sánh các công cụ xây dựng khác nhau ở cùng một nơi? Chúng tôi đã tiếp cận vấn đề này bằng cách viết các trường hợp kiểm thử.
Nhóm chúng tôi đã thảo luận và thiết kế các tiêu chí kiểm thử mà chúng tôi tin rằng chính là các phương pháp hay nhất để phát triển web. Chúng tôi đặc biệt tập trung vào cách cung cấp trải nghiệm người dùng nhanh, phản hồi và mượt mà, chủ ý loại trừ các bài kiểm thử liên quan đến trải nghiệm của nhà phát triển để tránh việc đo lường hai kết quả không thể so sánh được.
Sau khi tạo danh sách kiểm thử, chúng tôi tiếp tục viết một tập lệnh bản dựng cho từng công cụ để kiểm tra xem công cụ này có đáp ứng được các tiêu chí thành công của kiểm thử hay không. Trong nhóm ban đầu, chúng tôi quyết định tìm hiểu về webpack v4, Rollup v2 và Parcel v2. Chúng tôi cũng đã thử nghiệm Browserify + Gulp vì nhiều dự án vẫn sử dụng chế độ thiết lập này. Để kiểm thử thành công, bạn chỉ được sử dụng các tính năng được ghi công khai của công cụ hoặc trình bổ trợ cho công cụ. Sau khi viết bộ bài kiểm thử ban đầu, chúng tôi đã làm việc với các tác giả của công cụ xây dựng để đảm bảo chúng tôi sử dụng các công cụ của họ một cách chính xác và thể hiện chúng một cách công bằng.
Chúng tôi chỉ dùng ${tool_name} thôi, tôi vẫn cần quan tâm chứ?
Trong nhiều nhóm, có những người chuyên duy trì cơ sở hạ tầng xây dựng và các thành viên khác trong nhóm có thể không bao giờ phải lựa chọn các công cụ xây dựng. Chúng tôi hy vọng trang web này vẫn hữu ích cho bạn, để giúp bạn có kỳ vọng hợp lý đối với những công cụ mà bạn tin dùng. Đối với mỗi kiểm thử, chúng tôi có phần giải thích lý do tại sao kiểm thử lại quan trọng cùng với các tài nguyên bổ sung. Và nếu bạn muốn áp dụng phương pháp hay nhất bằng công cụ bạn chọn, thì chế độ thiết lập kiểm thử trong kho lưu trữ của chúng tôi sẽ chứa các tệp cấu hình cần thiết để thực hiện việc này.
Tôi có thể đóng góp cho trang web này không?
Nếu bạn cho rằng một tính năng nhất định cần được kiểm thử nhưng hiện còn thiếu, vui lòng đề xuất tính năng đó trong một vấn đề trong GitHub để bắt đầu thảo luận. Chúng tôi mong muốn đóng gói các trường hợp sử dụng trong thực tế. Chúng tôi hoan nghênh mọi hoạt động kiểm thử bổ sung giúp đánh giá những kết quả này tốt hơn.
Nếu bạn muốn viết mã kiểm thử cho các công cụ mà chúng tôi không đưa vào tập hợp ban đầu, chúng tôi cũng hoan nghênh bạn làm như vậy! Vui lòng xem trang CONTRIBUTING.md để biết thêm thông tin.