Bài gốc: https://manhhomienbienthuy.github.io/2018/05/20/tai-sao-nen-su-dung-eslint-cho-du-an.html (đã xin phép tác giả)
javascript đã trở thành một ngôn ngữ cực kỳ phổ biến trong lập trình web. hầu như bất kỳ nhà phát triển web nào cũng nên 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 mã javascript tốt hơn, đó là eslint.
Bạn đang xem: Eslint là gì
Ngày nay javascript đã phát triển khác xa so với thế hệ ban đầu, khi các thông số kỹ thuật của es2015 (ecmascript 2015 – es6) và es2017 được xuất bản. đặc biệt là nhiều thư viện javascript như reactjs, anglejs, vuejs, v.v. chúng giúp chúng tôi tạo ra các ứng dụng web cực kỳ thú vị.
Mặc dù có các thông số kỹ thuật như vậy, ngày nay vẫn còn nhiều vấn đề với mã hóa javascript. 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 một dự án tốt, chẳng hạn như: cấu trúc thư mục rõ ràng, readme đầy đủ thông tin, hướng dẫn cấu hình, cũng như xây dựng và kiểm tra. và 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, sức người không thể làm được tất cả. đó là lúc chúng ta cần các 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 tạo quy ước mã hóa ngay từ đầu để mọi người tuân theo. Quy ước mã hóa thường không làm cho mã chạy nhanh hơn, nhưng nó giúp giữ cho mã dễ đọc hơn.
Tôi đã trải qua một số dự án và thực sự đã sử dụng con người để đảm bảo rằng quy ước mã hóa là không thể tưởng tượng được do quá nhiều công việc. nhưng, ngay cả con người cũng có lúc mắc sai lầm, họ có thể bỏ qua lỗi lầm này, lỗi lầm kia nếu nó nhỏ trong quá trình kiểm điểm. do đó, tốt hơn là bạn nên bảo mật quy ước mã hóa bằng các công cụ tự động.
những thứ có tính chất cố định như vậy, máy tính luôn hoạt động tốt hơn con người. kết quả chính xác và nhanh chóng, các nhà phát triển sẽ có nhiều thời gian hơn để tạo và viết mã cho các hàm thay vì chọn lọc qua dấu chấm phẩy của người khác để làm đúng. công cụ giúp chúng tôi thực hiện việc 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ã, cho thấy các vấn đề mà mã đang gặp phải, chẳng hạn như không tuân thủ phong cách mã hóa, quy ước mã hóa sai. 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ã, 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ị của biến toàn cục gây khó khăn cho việc gỡ lỗi, v.v. ..
lint có thể là một vấn đề đau đầu đối với một số người, nhưng nó giúp làm cho mã rõ ràng hơn. Theo thời gian, khi quá trình diễn ra nhanh chóng, lông tơ sẽ trở thành một công cụ 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 có câu hỏi nào. javascript là ngôn ngữ chính được sử dụng, vì vậy tất nhiên chúng ta cần 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 một dự án tốt. không có quy tắc nào cả, mọi người viết mã theo những phong cách rất khác nhau sẽ tạo ra một mớ hỗn độn mà người lạ sẽ không hiểu (thậm chí 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 là javascript. javascript có thể không phải là ngôn ngữ quan trọng nhất trong dự án, nhưng tôi có thể chắc chắn rằng đó là ngôn ngữ cần người sử dụng nhất.
nguyên nhân đến từ chính ngôn ngữ. javascript có thiết kế xấu, cú pháp của nó là sự pha trộn giữa java và c ++, và nó pha trộn nhiều tính năng của các ngôn ngữ kịch bản như ruby, python.
chưa kể rằng ngôn ngữ được hỗ trợ trong các trình duyệt khác nhau là rấ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 trình duyệt khác. chắc chắn một số người trong chúng ta đã gặp ác mộng với Internet explorer. Để mã chạy trên các trình duyệt, gần như bắt buộc mã phải có mã dư thừa ngoài logic.
Do sự phức tạp của cú pháp, javascript có nhiều vấn đề. Bạn có thể đọc thêm ở đây. thực tế là es2015 được xuất bản chỉ giúp giảm bớt các vấn đề của nó, không loại bỏ nó hoàn toàn. chưa kể đến những thứ về hiệu suất, ngay cả cú pháp của nó cũng làm cho nó rất “linh hoạt”. chúng ta có thể thêm dấu cách và ngắt dòng theo ý muốn, điều này làm cho ngôn ngữ này trở thành ngôn ngữ có thể viết nhiều kiểu nhất trong một dự án.
do đó, dự án tiến triển theo thời gian, mã sẽ tăng dần lên mỗi ngày, mỗi nhà phát triển có phong cách và sở thích khác nhau khi viết mã, thậm chí cùng một người bây giờ mã một kiểu, ngày mai sẽ mã một kiểu, tận dụng lợi thế của javascript ở mức tối đa ngôn ngữ khó đồng nhất trong một dự án.
Ngay cả khi có quy ước mã hóa, hai người mã hóa cùng một logic có thể tạo ra mã “không liên quan” đến nhau.
một yếu tố khiến javascript khó duy trì tính nhất quán trong cách mã nguồn từ con người. hầu hết các nhà phát triển full stack mà tôi biết chỉ mạnh về phần phụ trợ, họ có các kỹ năng trên giao diện người dùng nhưng so với phần phụ trợ thì đó 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à sau khi xuất hiện reactjs, javascript ngày càng đóng vai trò quan trọng trong 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, giờ đây javascript đã đảm nhiệm hoàn toàn phần “hiển thị” của trang. đặc biệt là nhiều dự án, frontend chỉ là javascript và css, html thuần túy hầu như không được sử dụng nữa.
với những dự án như vậy, lint javascript là cần thiết hơn bao giờ hết.
có nhiều công cụ lint javascript khác nhau: eslint, jslint, jshint.
có so sánh các công cụ này, bạn có thể đọc để tham khảo. các công cụ có thể tóm tắt như sau: jslint rất hạn chế, nó không cho phép chúng tôi tùy chỉnh theo ý mình, jshint thiếu các cơ chế mở rộng, jscs chỉ thích hợp để kiểm tra kiểu mã hóa.
và cuối cùng eslint là công cụ hài hòa nhất, là lựa chọn tốt nhất cho các dự án. Nó cho phép chúng tôi tùy chỉnh cài đặt theo quy ước mã hóa của chúng tôi, kiểm tra kiểu mã hóa và tìm lỗi cũng như các vấn đề tiềm ẩn khác.
Xem thêm: Kỹ năng là gì? Những kỹ năng ai cũng phải có trong cuộc sống
eslint là một lựa chọn rất phù hợp nếu chúng ta sử dụng es2015 ngoài jsx (from react). Trong số tất cả các loại vải, nó là loại tuân thủ jsx tốt nhất từ es2015 và là loại duy nhất hiện đang tuân thủ jsx.
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. tuy nhiên ý kiến cá nhân của mình là nó vừa vặn nhất nên dùng cũng được.
eslint có thể được cài đặt qua npm đơn giản như sau
Bạn không cần phải viết mã nodejs để sử dụng node và npm. nhiều dự án đã sử dụng các gói nút để xây dựng các thành phần giao diện người dùng. thì có lẽ tôi không cần nói thêm về npm, nếu không chắc bạn 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 chức năng của nó. Ví dụ: tôi viết mã reactjs trong dự án của mình, tôi cần cài đặt plugin sau để eslint có thể hỗ trợ nó:
Một linter tốt chỉ có thể 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ì phục vụ để cải thiện chất lượng mã của chúng tôi, nó sẽ trở thành một trở ngại khi liên tục hiển thị lỗi ở những vị trí không chính xác.
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ứ về quy ước mã hóa đều có thể định cấu hình. 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. một cái gì đó như thế này:
Cách này có nhược điểm là với mỗi tệp chúng ta phải đặt một lần, nhưng nhiều lần thì số lượng chú thích này rất lớn vì chúng ta cần đặt nhiều thứ khác nhau trong quy ước. vì vậy cách hiệu quả nhất 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 tôi vẫn có thể sử dụng nhận xét trên một số tệp nếu các tệp đó được yêu cầu mã hóa khác.
eslint sử dụng tệp cấu hình, được gọi là .eslintrc. *, phần mở rộng có thể là js, yaml, yml, json tương ứng với định dạng của tệp đó hoặc nó ghi cấu hình trực tiếp 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 điều đó sẽ 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 cho eslint có các thành phần chính sau:
phần bổ sung
Đây là những plugin được sử dụng để mở rộng chức năng của eslint. ví dụ: eslint không hỗ trợ kiểm tra cú pháp jsx linh hoạt, vì vậy chúng tôi bắt buộc phải sử dụng plugin để kiểm tra các mã đó.
tiện ích mở rộng
Đây là những cài đặt 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ài đặt của riêng mình. eslint có một cơ chế tốt cho phép chúng ta “sử dụng lại” các thiết lập của người khác. ví dụ: tôi muốn sử dụng cài đặt tích hợp eslint: suggest (eslint built-in) và react / Recommend (plugin tích hợp sẵn), sau đó tôi định cấu hình như sau:
Tương tự, chúng tôi có thể sử dụng cài đặt của mọi người nếu chúng tôi cho rằng nó phù hợp, ví dụ: ví dụ: Strongloop. chúng ta có thể cài đặt gói tương ứng và mở rộng nó. lưu ý rằng chúng ta cần tìm hiểu thêm về các cài đặt có sẵn này, đôi khi chúng rất tiện lợi nhưng nếu không phù hợp thì không nên sử dụng, kể cả những cài đặt “được khuyến nghị”.
quy tắc
Đây là phần cấu hình của các quy tắc mà mã phải tuân theo. có 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 nữa. ở đây, chúng tôi chỉ cần định cấu hình thêm các quy tắc mà chúng tôi cần tùy chỉnh.
mỗi quy tắc phải được định cấu hình với hai tham số: giá trị tương ứng với mức quy tắc được áp dụng (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 cung cấp hoặc các quy tắc từ các plugin.
ví dụ: quy tắc sau yêu cầu áp dụng dấu nháy đơn ‘cho các chuỗi trong mã và kiểm tra xem phản ứng nhập có thành công hay không, nếu không, quy tắc này sẽ báo lỗi với mã thoát là 1.
số lượng quy tắc được eslint hỗ trợ là rất lớn, hầu hết mọi yếu tố của mã đều được hỗ trợ, chưa kể plugin còn mở rộng hơn nữa. bạn có thể xem tất cả các quy tắc eslint tại đây.
tùy chọn phân tích
theo mặc định, eslint kiểm tra cú pháp es5, nếu bạn 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. cũng nên đặt hỗ trợ jsx ở đâ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 thiết lập môi trường mà mã của chúng tôi sẽ chạy. 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ư window, document, môi trường es6 sẽ có một số kiểu dữ liệu mới như set.
toàn cầu
Xem thêm: Blender là gì? Có tính năng nào nổi bật? Có nên dùng không?
đâ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 tôi truy cập một biến nhất định, eslint sẽ báo lỗi vì quyền truy cập vào một biến không được xác định.
Các biến toàn cục có thể được xác định bằng các nhận xét trong chính tệp hoặc danh sách đầy đủ trong tệp cấu hình.
một số biến toàn cục không cần phải được định nghĩa lại (như window, document) nếu env đã định nghĩa nó.
javascript có một đối tượng chứa dữ liệu được truyền đến các đối số của hàm mà không thấy bất kỳ môi trường nào xác định nó. nếu chúng ta muốn sử dụng đối tượng này, chúng ta phải đưa nó vào cấu hình toàn cầu.
Ngoài những phần chính đã trình bày, eslint còn có nhiều cấu hình khác. bạn có thể tham khảo tại đây để biết thêm chi tiết về cách tùy chỉnh eslint theo ý thích của bạn.
ví dụ
Dưới đây là toàn bộ thiết lập eslint mà tôi đang sử dụng để mã phản ứng (redux) lint.
sau khi chúng tôi đã định cấu hình eslint, công việc còn lại của chúng tôi là áp dụng nó vào dự án, làm cho nó hoạt động như một linter.
Đầu tiên, chúng tôi cần thêm một tập lệnh để gọi sau (tệp package.json):
Việc sử dụng tập lệnh nào 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 script đặt trước hoặc post test, để eslint chạy tự động mỗi khi unit test được gọi. với một dự án web thông thường, bạn có thể đặt tên cho tập lệnh sao cho dễ nhớ.
sau khi có script, mỗi khi cần gọi eslint, chúng ta chỉ cần thực hiện như sau:
nếu bạn chưa bao giờ sử dụng linter hoặc nếu bạn có ít kinh nghiệm, có thể mỗi lần thực thi lint sẽ là một (các) trang đầy lỗi. đối với những người yếu đuối, họ có thể bị sốc và chán nản và không muốn viết mã nữa.
thật may mắn với 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 có thể sửa nhiều lỗi, nhưng không phải tất cả. bạ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 ta rất nhiều, ít nhất thì số lượng lỗi cũng đã giảm đi đáng kể, nhìn thì có vẻ tương lai hơn.
nếu bạn muốn một công cụ gỡ lỗi mạnh mẽ hơn, bạn có thể sử dụng đẹp hơn (tham khảo). đây là một công cụ chuyên về định dạng mã, vì vậy nó mạnh hơn eslint để sửa lỗi. sử dụng kết hợp giữa eslint và beautiful sẽ cho kết quả rất tốt (mặc dù không thể đúng 100%).
Ở trên, tôi đã trình bày cách áp dụng eslint cho dự án, gõ lệnh mỗi lần. 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 một số nghiên cứu, tôi đã tìm ra một cách, đó 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 mỗi khi chúng tôi cam kết. nếu bạn đã sử dụng precommit git trước đây, bạn chỉ cần chỉnh sửa tệp .git / hooks / pre-commit; nếu không, chúng tôi cần tạo tệp đó.
cách dễ nhất là sử dụng tệp mẫu do git cung cấp:
Nội dung của tệp sẽ có hai dòng cuối như sau:
chúng tôi sẽ thêm cách gọi eslint như vậy:
vì vậy, bây giờ, mọi commit, 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 xây dựng lại. tuy nhiên, watchify rất khó gọi eslint mỗi khi nó thay đổi. nếu muốn, chúng tôi phải chuyển sang sử dụng các công cụ xây dựng khác như gulp hoặc grunt.
Hai công cụ này cho phép chúng ta tùy chỉnh rất nhiều, chúng có cơ chế cho phép thực thi nhiều hơn một tác vụ khi một tệp tin thay đổi. nhược điểm là watchify có cơ chế lưu vào bộ nhớ đệm khiến việc xây dựng mã khi có thay đổi nhanh hơn nhiều, sử dụng gulp hoặc grunt mã xây dựng sẽ luôn được thực hiện từ đầu nên 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 đề khi 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, nằm ngoài phạm vi của bài viết này, vì vậy tôi sẽ không trình bày nhiều ở đâ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. do đó, nếu muốn ứng tuyển, bạn phải tìm được sự đồng thuận của đồng nghiệp.
eslint là một công cụ tuyệt vời, hãy sử dụng nó thường xuyên. Mình hy vọng bài viết sẽ giúp ích được phần nào cho bạn và code của bạn sẽ ngày càng đẹp hơn.
Xem thêm: Uống nước rau diếp cá có tác dụng gì
