Hãy sử dụng ESLint cho dự án của bạn!

Bài gốc: https://manhhomienbienthuy.github.io/2018/05/20/tai-sao-nen-su-dung-eslint-cho-du-an.html (cần có sự cho phép của tác giả)

javascript đã trở thành một ngôn ngữ rất phổ biến trong lập trình web. Hầu như tất cả các nhà phát triển web đều phải biết mã javascript. Nhưng biết là một chuyện, mã tốt là một chuyện khác. Trong bài viết này, mình sẽ giới thiệu một công cụ giúp chúng ta viết javascript tốt hơn, đó là eslint.

Javascript hiện tại đã có một chặng đường dài so với thế hệ ban đầu, khi thông số kỹ thuật es2015 (ecmascript 2015 – es6) và es2017 được phát hành. Đặc biệt là reactjs, anglejs, vuejs và nhiều thư viện javascript khác giúp chúng ta xây dựng các ứng dụng web cực hay.

Bất chấp đặc điểm kỹ thuật này, vẫn còn nhiều vấn đề với mã hóa javascript ngày nay. Do đó, việc đảm bảo chất lượng của mã javascript vẫn là một thách thức lớn.

Có nhiều yếu tố tốt để tạo ra một dự án tốt, chẳng hạn như: cấu trúc thư mục rõ ràng, tệp readme nhiều thông tin, hướng dẫn thiết lập và xây dựng, thử nghiệm. Yếu tố quan trọng nhất của một dự án tốt phải là mã dễ đọc, dễ hiểu và dễ bảo trì.

Để đảm bảo những yếu tố này, con người không thể làm được tất cả. Đây là lúc chúng ta cần một công cụ xơ vải.

Nếu bạn muốn dự án của mình có mã đủ tốt, bạn cần thiết lập các quy ước mã hóa ngay từ đầu mà mọi người đều tuân theo. Các quy ước mã hóa thường không làm cho mã chạy nhanh hơn, nhưng nó giúp duy trì mã dễ đọc hơn.

Tôi đã thực hiện một số dự án và do khối lượng công việc quá lớn, việc sử dụng con người để đảm bảo các quy ước mã hóa là điều không tưởng. Tuy nhiên, ngay cả con người đôi khi cũng mắc lỗi, điều này có thể bỏ qua nếu lỗi nhỏ trong quá trình xem xét. Vì vậy, tốt nhất là sử dụng các công cụ tự động để đảm bảo các quy ước mã hóa.

Máy tính luôn làm tốt hơn những thứ có tính chất cố định này hơn con người. Kết quả vừa chính xác vừa nhanh chóng và nhà phát triển sẽ có nhiều thời gian hơn để tạo và viết mã cho hàm, thay vì kiểm tra xem dấu chấm phẩy của người khác có đúng hay không. Các công cụ giúp chúng ta thực hiện điều này được gọi là công cụ lint (linter).

Lints là công cụ giúp chúng tôi phân tích mã của mình, tiết lộ các vấn đề mà mã của chúng tôi gặp phải, chẳng hạn như mã hóa không đúng phong cách, quy ước mã hóa không hợp lệ. Ngoài ra, lint cũng có thể giúp chúng tôi tìm ra một số lỗi tiềm ẩn trong mã của chúng tôi, chẳng hạn như gán các biến không được khai báo, có thể gây ra lỗi thời gian chạy hoặc nhận giá trị từ các biến toàn cục gây khó khăn cho việc gỡ lỗi, v.v. ..

lint có thể hơi đau đầu đối với một số người, nhưng nó giúp làm cho mã sạch hơn. Theo thời gian, khi quá trình này tăng lên, xơ vải sẽ là một chất hỗ trợ kiểm tra rất hữu ích.

Nếu bạn là một lập trình viên nodejs, không nghi ngờ gì nữa. javascript là ngôn ngữ chính được sử dụng, vì vậy tất nhiên chúng ta cần một linter.

Ở đây tôi đang đề cập đến các dự án phát triển web khác sử dụng nhiều ngôn ngữ khác nhau, từ phụ trợ (ruby, php, python, v.v.) đến giao diện người dùng (html, javascript, scss, v.v.)

Trong một dự án, tất cả các ngôn ngữ, bao gồm html và css, phải tuân theo các quy tắc để tạo ra một dự án tốt. Không có quy tắc, mọi người đều có một phong cách viết mã rất khác nhau, tạo ra sự nhầm lẫn mà người ngoài không thể hiểu được (thậm chí họ không muốn đọc).

Tuy nhiên, trong bài viết này, tất cả các ngôn ngữ chính đều là javascript. JavaScript có thể không phải là ngôn ngữ quan trọng nhất đối với một dự án, nhưng tôi có thể nói chắc chắn rằng nó là ngôn ngữ cần người nói nhiều nhất.

Lý do đến từ chính ngôn ngữ. javascript được thiết kế tồi, cú pháp của nó là sự pha trộn giữa java và c ++, và rất nhiều tính năng từ các ngôn ngữ kịch bản như ruby, python, v.v.

Chưa kể, hỗ trợ ngôn ngữ rất khác nhau trên các trình duyệt khác nhau. Mỗi trình duyệt sử dụng công cụ riêng của nó, vì vậy nhiều tính năng hoạt động trong một trình duyệt này có thể không hoạt động trong một trình duyệt khác. Tất nhiên, bất kỳ ai trong chúng ta cũng từng gặp ác mộng với Internet explorer. Để mã hoạt động trên các trình duyệt, mã phải có mã dự phòng vượt quá logic.

JavaScript gặp nhiều vấn đề do sự phức tạp của cú pháp. Bạn có thể đọc thêm ở đây. Việc phát hành es2015 chỉ giúp giảm bớt các vấn đề của nó, không loại bỏ nó hoàn toàn. Không đề cập đến các công cụ hiệu suất, ngay cả cú pháp của nó làm cho nó rất “linh hoạt”. Chúng tôi có thể thêm dấu cách và dòng mới theo ý muốn, làm cho nó trở thành ngôn ngữ mà hầu hết các kiểu có thể được mã hóa trong dự án.

Vì vậy, khi dự án tiến triển, theo thời gian, mã sẽ tăng dần lên từng ngày, mỗi nhà phát triển có một phong cách và sở thích khác nhau khi viết mã, thậm chí cùng một người viết mã một kiểu ngay bây giờ và ngày mai mã một kiểu khiến JavaScript trở thành ngôn ngữ khó nhất để đồng nhất trong các dự án.

Ngay cả với các quy ước mã hóa, hai người viết cùng một lôgic vẫn có thể tạo ra mã có vẻ “không liên quan” đến nhau.

Một yếu tố khiến javascript khó nhất quán trong cách mã nguồn gốc của con người. Hầu hết các nhà phát triển full stack mà tôi biết chỉ giỏi ở phần phụ trợ, họ có các kỹ năng trong giao diện người dùng, nhưng so với phần phụ trợ, đó thực sự là một thế giới. Ngoài ra, giao diện người dùng là một phần dễ bị bỏ qua của dự án vì mọi người tập trung nhiều hơn vào hiệu suất, tối ưu hóa mã, cơ sở dữ liệu, v.v.

Gần đây, đặc biệt là với sự xuất hiện của reactjs, javascript ngày càng đóng một vai trò quan trọng trong các dự án. Thay vì chỉ là một phần nhỏ, hỗ trợ một số hiệu ứng giúp trang đẹp hơn, javascript giờ đây đã chiếm lĩnh hoàn toàn phần “hiển thị” của trang. Đặc biệt là đối với nhiều dự án, giao diện người dùng chỉ có javascript và css, còn html thuần túy gần như vô dụng.

Đối với những dự án như thế này, javascript lint cần thiết hơn bao giờ hết.

Có nhiều công cụ lint javascript khác nhau: eslint, jslint, jshint.

Dưới đây là so sánh các công cụ này để tham khảo. Có thể tóm tắt các công cụ như sau: jslint rất hạn chế và không cho phép chúng ta tùy chỉnh theo ý muốn, jshint thiếu cơ chế mở rộng và jscs chỉ thích hợp để kiểm tra kiểu mã hóa.

Cuối cùng, eslint là công cụ được phối hợp nhiều nhất và là lựa chọn tốt nhất cho một dự án. Nó cho phép chúng tôi tùy chỉnh cấu hình theo quy ước mã hóa của chúng tôi, kiểm tra phong cách mã hóa và tìm lỗi và các vấn đề tiềm ẩn khác.

Nếu chúng ta sử dụng es2015 và jsx (react) thì eslint là một lựa chọn rất phù hợp. Trong tất cả các linter, nó là trình hỗ trợ jsx es2015 tốt nhất và là ứng dụng duy nhất hỗ trợ jsx tại thời điểm hiện tại.

Tất nhiên, nhiều tính năng hơn có nghĩa là nó sẽ chạy chậm hơn. Vì vậy, trong một số dự án nó có thể không phải là công cụ phù hợp nhất. Nhưng ý kiến ​​cá nhân của mình thì nó là phù hợp nhất nên dùng được.

Có thể cài đặt eslint qua npm, thật dễ dàng

Bạn có thể sử dụng nút và npm mà không cần viết mã nodejs. Nhiều dự án sử dụng các gói nút để xây dựng các thành phần front-end. Vì vậy có lẽ tôi không cần nói thêm về npm, nếu bạn chưa rõ thì có thể đọc thêm tại đây.

Ngoài ra, eslint cũng cho phép chúng tôi sử dụng các plugin để mở rộng hoạt động của nó. Ví dụ: tôi đã viết reactjs trong dự án của mình và tôi cần cài đặt plugin sau để eslint có thể hỗ trợ nó:

Một linter tốt sẽ chỉ hoạt động nếu chúng ta định cấu hình nó một cách chính xác. Nếu không, thay vì cải thiện chất lượng mã của chúng tôi, nó có thể là một trở ngại bằng cách liên tục đưa ra các lỗi ở những vị trí sai.

eslint là một công cụ rất linh hoạt cho phép chúng tôi định cấu hình nó rất dễ dàng. Mọi thứ liên quan đến quy ước mã hóa đều có thể cấu hình được. Có hai cách để cấu hình eslint, cách đầu tiên là bình luận trực tiếp trong mã javascript. Như thế này:

Có một nhược điểm của cách tiếp cận này. Đối với mỗi tệp, chúng ta phải định cấu hình nó một lần, nhưng nhiều lần chú thích này rất lớn, vì chúng ta cần định cấu hình nhiều thứ khác nhau trong quy ước. Vì vậy, một cách hiệu quả hơn là sử dụng một tệp cấu hình chung áp dụng cho toàn bộ dự án. Nhưng chúng ta vẫn có thể sử dụng chú thích trong một số tệp nếu chúng ta cần mã hóa chúng theo cách khác.

eslint sử dụng tệp cấu hình có tên .eslintrc. *, phần mở rộng có thể là js, yaml, yml, json tương ứng với định dạng tệp hoặc bạn có thể ghi trực tiếp cấu hình vào tệp package.json.

Cá nhân tôi thích sử dụng json hơn, vì vậy tôi sẽ định cấu hình eslint trong tệp .eslintrc.json. Sử dụng package.json luôn thuận tiện, nhưng nó làm cho tệp lớn không cần thiết, vì vậy tôi nghĩ tốt hơn nên sử dụng một tệp riêng biệt.

Tệp cấu hình của eslint có các thành phần chính sau:

Plugin

Đây là các plugin để mở rộng hoạt động eslint. Ví dụ, eslint không hỗ trợ kiểm tra cú pháp jsx thần thánh, khi đó chúng ta phải sử dụng các plugin để kiểm tra các mã này.

Tiện ích mở rộng

Đây là những cấu hình tích hợp được sử dụng, chúng tôi sẽ mở rộng chúng bằng cách thêm cấu hình của chúng tôi. eslint có một cơ chế tốt cho phép chúng ta “tái sử dụng” cấu hình của người khác. Ví dụ: tôi muốn sử dụng cấu hình eslint tích hợp: Recommended (eslint cài sẵn) và react / Recommend (plugin tích hợp sẵn), sau đó tôi định cấu hình như sau:

Một lần nữa, chúng tôi có thể sử dụng cấu hình của mọi người nếu chúng tôi thấy phù hợp, chẳng hạn như strongloop. Chúng tôi có thể cài đặt gói tương ứng và mở rộng nó. Lưu ý là chúng ta nên tìm hiểu thêm về những cấu hình có sẵn này, đôi khi chúng tiện lợi nhưng nếu không phù hợp thì không nên sử dụng, thậm chí là những cấu hình “khuyến nghị”.

Quy tắc

Đây là phần định cấu hình các quy tắc mà mã cần tuân theo. Có rất nhiều quy tắc được cấu hình sẵn, khi chúng ta mở rộng một cấu hình thì không cần phải cấu hình lại. Ở đây, chúng ta chỉ cần cấu hình thêm các quy tắc cần được tùy chỉnh.

Mỗi quy tắc yêu cầu hai tham số được định cấu hình: giá trị tương ứng với mức áp dụng quy tắc (tắt, cảnh báo, lỗi hoặc 0, 1, 2 cho ngắn gọn) và các tùy chọn. Các quy tắc ở đây có thể là các quy tắc do eslint hoặc các quy tắc plugin cung cấp.

Ví dụ: quy tắc sau yêu cầu các chuỗi trong mã sử dụng dấu nháy đơn ‘và kiểm tra xem phản ứng nhập có chính xác hay không, nếu không sẽ báo lỗi và mã thoát sẽ là 1.

eslint hỗ trợ một số lượng rất lớn các quy tắc, hầu như tất cả các phần tử mã đều được hỗ trợ, chưa kể đến một loạt các plugin. Bạn có thể xem tất cả các quy tắc eslint ở đây.

Tùy chọn phân tích cú pháp

Theo mặc định, eslint kiểm tra cú pháp es5, nếu sử dụng es6 trở lên, chúng tôi phải định cấu hình nó bằng cách sử dụng phân tích cú pháp. Ngoài ra, hỗ trợ jsx cũng cần được định cấu hình tại đây. Cấu hình hoàn chỉnh cho phần này như sau:

Môi trường

Đây là nơi chúng tôi định cấu hình môi trường thời gian chạy mã của mình. Các môi trường khác nhau có các biến toàn cục khác nhau. Ví dụ, môi trường trình duyệt sẽ có các biến như cửa sổ và tài liệu, và môi trường es6 sẽ có các kiểu dữ liệu mới như set.

Biến toàn cục

Đây là nơi chúng tôi cung cấp danh sách các biến toàn cục được sử dụng trong dự án. Nếu không, khi chúng ta truy cập một biến, eslint sẽ báo lỗi vì quyền truy cập vào biến không được xác định.

Các biến toàn cục có thể được xác định thông qua nhận xét trong chính tệp hoặc trong tệp cấu hình bằng cách sử dụng danh sách đầy đủ.

Nếu env đã xác định một số biến toàn cục (như window, document), bạn không cần phải xác định lại nó.

javascript có một đối tượng chứa dữ liệu được truyền đến các tham số hàm mà không thấy bất kỳ môi trường nào mà nó được xác định. Nếu chúng ta muốn sử dụng đối tượng này, chúng ta phải đưa nó vào biến toàn cục config.

Ngoài phần chính của phần giới thiệu, eslint còn có nhiều cấu hình khác. Bạn có thể tham khảo thêm tại đây để biết thêm chi tiết tùy chỉnh eslint theo ý thích của mình.

Ví dụ

Dưới đây là cấu hình đầy đủ của eslint mà tôi sử dụng để lint mã phản ứng (redux).

Sau khi chúng tôi đã định cấu hình eslint, tất cả những gì còn lại là áp dụng nó vào dự án và làm cho nó hoạt động như một linter.

Đầu tiên, chúng ta cần thêm một tập lệnh (tệp package.json) để được gọi sau:

Tập lệnh nào được sử dụng tùy thuộc vào từng dự án. Nếu đó là một dự án nodejs, thì chúng ta có thể sử dụng các cài đặt trước tập lệnh hoặc posttest, sẽ tự động chạy eslint mỗi khi một bài kiểm tra đơn vị được gọi. Đối với các dự án web thông thường, bạn có thể đặt tên cho tập lệnh của mình để dễ nhớ hơn.

Sau khi có script, mỗi khi cần gọi eslint, chúng ta chỉ cần đơn giản:

Nếu bạn chưa bao giờ sử dụng linter hoặc người chưa có kinh nghiệm, mỗi lần chạy lint có thể là một trang đầy lỗi. Đối với những người thiểu năng, họ có thể bị sốc và thất vọng và không muốn code nữa.

Cảm ơn eslint, họ đã giúp chúng tôi giải quyết (một phần) vấn đề. eslint có thể tự động sửa một số lỗi bằng cách thêm tùy chọn -fix, chúng tôi có thể thêm tùy chọn này trực tiếp trong tập lệnh ở trên hoặc gọi nó theo cách thủ công

eslint sửa được nhiều lỗi, nhưng không phải tất cả. Nó chỉ có thể sửa mã được đảm bảo không ảnh hưởng đến hoạt động. Tuy nhiên, nó đã giúp ích cho chúng tôi rất nhiều, ít nhất là số lượng lỗi đã được giảm đi rất nhiều, và nhìn vào nó sẽ thấy nhiều hơn trong tương lai.

Nếu bạn muốn các công cụ gỡ lỗi mạnh mẽ hơn, bạn có thể sử dụng đẹp hơn (tham khảo). Đó là một công cụ chuyên về định dạng mã, vì vậy nó mạnh hơn so với việc sửa lỗi. Sử dụng kết hợp giữa eslint và beautiful sẽ tạo ra kết quả rất tốt (mặc dù nó không đúng 100%).

Ở trên, tôi đã hướng dẫn cách áp dụng eslint cho một dự án, gõ lệnh mọi lúc. Việc phải gõ cùng một lệnh hàng chục lần một ngày là điều nhàm chán không thể tả, ít nhất là đối với tôi. Vì vậy, nếu có một cách để tự động hóa mọi thứ, điều đó sẽ thật hoàn hảo.

Sau khi nghiên cứu, tôi đã tìm ra cách để thực hiện việc này, đó là sử dụng cam kết trước git hook. Sử dụng git hook sẽ giúp chúng tôi chạy eslint trên mọi cam kết. Nếu bạn đã sử dụng git hook pre-commit trước đây, bạn chỉ cần chỉnh sửa tệp .git / hooks / pre-commit, nếu không chúng ta cần tạo tệp đó.

Cách dễ nhất là sử dụng các tệp mẫu do chính git cung cấp:

Hai dòng cuối cùng của nội dung tệp như sau:

Chúng tôi sẽ thêm lệnh gọi eslint như sau:

Vì vậy, bây giờ, mọi cam kết, eslint sẽ được gọi hoàn toàn tự động:

Ngoài ra, chúng tôi vẫn có thể sử dụng watchify để theo dõi các thay đổi mã và tự động tạo lại. Tuy nhiên, watchify làm cho nó khó gọi là eslint trên mỗi thay đổi. Nếu cần, chúng tôi phải sử dụng các công cụ xây dựng khác như gulp hoặc grunt để thay thế.

Hai công cụ này cho phép chúng tôi thực hiện nhiều tùy chỉnh và chúng có cơ chế cho phép nhiều tác vụ chạy khi tệp thay đổi. Nhược điểm là watchify có cơ chế lưu vào bộ nhớ đệm để xây dựng mã nhanh hơn khi có thay đổi, việc xây dựng mã bằng gulp hoặc grunt sẽ luôn được thực hiện từ đầu, vì vậy sẽ mất nhiều thời gian hơn. (Tuy nhiên, cơ chế bộ nhớ đệm của watchify có một số vấn đề với việc thêm và xóa tệp.)

Một công cụ mới nổi khác là webpack, cũng cho phép chúng tôi sử dụng lệnh gọi eslint rất thuận tiện, bằng cách sử dụng eslint-loader.

Định cấu hình các công cụ này là một vấn đề khác và nằm ngoài phạm vi của bài viết này, vì vậy tôi sẽ không đi sâu vào quá nhiều chi tiết ở đây. Lưu ý rằng không giống như sử dụng git hook, sử dụng các công cụ này sẽ áp dụng tự động hóa cho toàn bộ dự án, điều này thật tuyệt vời nhưng không phải ai cũng thích. Vì vậy, nếu muốn ứng tuyển, bạn nên thống nhất ý kiến ​​với đồng nghiệp.

eslint là một công cụ tuyệt vời và tôi sử dụng nó rất nhiều. Hy vọng bài viết này giúp ích cho bạn và làm cho code của bạn ngày càng đẹp hơn.