Hãy nhìn nhận thực tế. Hầu hết chúng ta thích tạo các tính năng mới và giao diện người dùng hơn là các tác vụ bảo trì như dọn dẹp mã, cấu hình dự án và quản lý phụ thuộc.
Nhiều thứ nhàm chán và lặp đi lặp lại, như định dạng và kiểm tra lỗi, chủ yếu là các vấn đề đã được giải quyết bằng các công cụ như Prettier, ESLint và TypeScript.
Tuy nhiên, có một lĩnh vực khác thường không nhận được nhiều sự chú ý: xử lý các tệp, xuất và phụ thuộc không sử dụng. Điều này đặc biệt đúng khi các dự án phát triển theo thời gian, ảnh hưởng tiêu cực đến khả năng bảo trì cũng như sự nhiệt tình của chúng ta đối với nó. Những hiện vật không sử dụng này thường không được chú ý vì chúng thường khó tìm.
Bạn bắt đầu tìm kiếm những thứ không sử dụng ở đâu? Tôi cá là bạn đã thực hiện tìm kiếm toàn cầu cho một phụ thuộc để tìm hiểu xem nó có còn được sử dụng không. Bạn có biết rằng bạn có thể nhấp chuột phải vào một tệp và "Tìm tham chiếu tệp" trong VS Code không? Đây là những điều bạn không nên phải làm. Chúng là những nhiệm vụ tẻ nhạt có thể — và nên — được tự động hóa.
Tôi rất vui khi tìm thấy một số công cụ hiện có, chẳng hạn như ts-prune. Sau một số lần chạy ban đầu, tôiphát hiện ra rằng cơ sở mã của chúng tôi yêu cầu rất nhiều cấu hình và vẫn tạo ra nhiều kết quả dương tính giả. Tôi đã nghiên cứu cách các cơ sở mã khác cố gắng duy trì sự gọn gàng và nhận ra rằng có một cơ hội lớn trong không gian này.
Trên đường đi, tôi cũng tìm thấy depcheck, công cụ này xử lý rất nhiều tính phức tạp và tùy chỉnh trong các dự án JavaScript. Và sau đó là unimported, công cụ này cũng thực hiện một công việc đáng chú ý là tìm các tệp tin bị treo và các phụ thuộc chưa sử dụng.
Nhưng không có công cụ nào trong số này xử lý dự án của tôi tốt. Việc tôi phải sử dụng kết hợp các công cụ này sẽ không phải là vấn đề lớn, nhưng tôi không thể cấu hình đúng để xử lý các tùy chỉnh của dự án mà không báo cáo quá nhiều kết quả dương tính giả hoặc bỏ qua quá nhiều nội dung của dự án và để lại một điểm mù lớn.
Cuối cùng, các công cụ trong lĩnh vực này chỉ được sử dụng khi chúng được tự động hóa hoàn toàn và có thể bao quát toàn bộ dự án. Một điều nữa là không có công cụ nào hiện có hỗ trợ monorepos, một cấu trúc cho các kho lưu trữ gần đây đã trở nên phổ biến rộng rãi. Cuối cùng nhưng không kém phần quan trọng, cả ts-prune và depcheck đều ở chế độ bảo trì, nghĩa là chúng có thể sẽ không bao giờ hỗ trợ monorepos.
Trong quá trình này, tôi cũng ngày càng tin rằng một công cụ duy nhất để tìm tất cả các danh mục những thứ không sử dụng là một ý tưởng hay: mỗi danh mục đều yêu cầu đọc và phân tích các tệp nguồn và vì đây là một nhiệm vụ tương đối tốn kém, tôi nghĩ rằng con đường hiệu quả là theo dõi chúng cùng một lúc.
Nói một cách đại khái, có hai cách để xem Knip. Trong các dự án mới, thật tuyệt khi cài đặt Knip và để nó phát triển cùng với dự án. Giữ cho kho lưu trữ gọn gàng và chạy Knip theo cách thủ công hoặc trong môi trường tích hợp liên tục (CI) tự động.
Một cách khác để xem xét Knip là trong các dự án lớn hơn. Knip là một người bạn đồng hành tuyệt vời cho việc dọn dẹp khi xác định các tệp, bản xuất và phụ thuộc chưa sử dụng. Có thể có những kết quả dương tính giả ban đầu, nhưng việc bỏ qua chúng dễ hơn nhiều so với việc tự mình mò kim đáy bể.
Ngoài ra, trong hoặc sau những nỗ lực tái cấu trúc lớn, Knip có thể là một trợ lý tuyệt vời để dọn dẹp mọi thứ. Con người thường bỏ lỡ hoặc quên những thứ không còn sử dụng nữa, đặc biệt là khi những thứ đó không gần với công việc tái cấu trúc.
Knip hoạt động với JavaScript truyền thống và TypeScript hiện đại, có hỗ trợ tích hợp cho monorepos, hoạt động với bất kỳ trình quản lý gói nào và có nhiều tính năng, lớn nhỏ, giúp bạn duy trì các dự án của mình.
Trong khi đó, Knip theo dõi các phụ thuộc bên ngoài đã nhập và so sánh chúng với các phụ thuộc trong
Để tôi cho bạn cái nhìn sâu hơn về bên trong.
Nhưng chế độ này có thể bỏ lỡ cơ hội cắt xén. Ví dụ, các tệp hoặc tệp xuất chỉ được nhập bằng các bài kiểm tra thường không được báo cáo là chưa sử dụng. Tuy nhiên, khi tệp xuất không được sử dụng ở bất kỳ nơi nào khác, bạn có thể xóa cả tệp xuất và các bài kiểm tra của tệp đó!
Đây là lý do tại sao Knip có chế độ sản xuất. Chế độ này nghiêm ngặt hơn chế độ mặc định, trong đó Knip sẽ chỉ sử dụng mã sản xuất làm tệp nhập và chỉ xem xét
Nhưng vẫn còn nhiều hơn thế nữa. Các môi trường CI, như Azure và GitHub Actions, được cấu hình bằng các tệp YAML cũng có thể sử dụng cùng các công cụ dòng lệnh.
Và cuối cùng, các tập lệnh tùy chỉnh có thể sử dụng các công cụ dòng lệnh bằng cách tạo ra các quy trình con, sử dụng API Node.js gốc hoặc với các thư viện như
Knip có số lượng phát hiện như vậy ngày càng tăng để giữ cho các dự án của bạn gọn gàng và ngăn nắp, tái cấu trúc sau tái cấu trúc. Tuy nhiên, điều gì thú vị ở các tập lệnh đó? Chúng có thể phức tạp để phân tích cú pháp, khiến việc trích xuất các phụ thuộc của chúng trở nên khó khăn. Hãy xem một ví dụ:
Tại đây, chúng ta có thể tìm thấy
Bây giờ, nếu tập lệnh này được cập nhật hoặc xóa, Knip sẽ cho bạn biết nếu bất kỳ dependency hoặc tệp nào không còn được sử dụng nữa. Mặt khác, Knip cũng sẽ cho bạn biết nếu một dependency được sử dụng nhưng không được liệt kê rõ ràng trong
Vì không có cách chung nào để xử lý vô số biến thể, Knip hỗ trợ plugin. Knip có các plugin cho các công cụ có thể tham chiếu đến các phụ thuộc cần được liệt kê trong
Điều quan trọng đối với plugin là cách tham chiếu các dependency. Chúng có thể được nhập vào JavaScript giống như bất kỳ tệp nguồn nào khác và Knip cũng có thể phân tích cú pháp chúng như vậy. Tuy nhiên, chúng thường được tham chiếu dưới dạng chuỗi, giống như những gì ESLint thực hiện với các tùy chọn
Nhưng một số khung làm việc với các tệp không chuẩn, chẳng hạn như Vue, Svelte, MDX và Astro. Knip cho phép bạn cấu hình trình biên dịch để bao gồm các loại tệp này để chúng cũng có thể được đưa vào phân tích.
Nhưng để hỗ trợ monorepos và trình biên dịch trong khi vẫn duy trì hiệu suất tốt, tôi nhận ra rằng mình phải làm việc trực tiếp với phần phụ trợ TypeScript. Điều này đòi hỏi rất nhiều nỗ lực, nhưng nó cung cấp nhiều tính linh hoạt hơn, cũng như các cơ hội để tối ưu hóa nhiều hơn. Ví dụ: Knip chỉ có thể duyệt qua cây cú pháp trừu tượng (AST) của bất kỳ tệp nào một lần để tìm mọi thứ cần thiết.
Knip cũng cho phép bạn xác định một trình báo cáo tùy chỉnh. Knip sẽ gọi hàm của bạn với kết quả phân tích. Sau đó, bạn có thể làm bất cứ điều gì với nó, như ghi kết quả vào tệp hoặc gửi đến dịch vụ để theo dõi tiến trình theo thời gian.
Một kết quả dương tính giả thường có một trong ba nguyên nhân sau:
Khi bạn đang sử dụng Knip và thích thú với nó, đừng để các kết quả dương tính giả làm bạn sợ mà hãy báo cáo chúng. Vui lòng cung cấp một trường hợp kiểm tra có thể tái tạo được và tôi chắc chắn chúng ta có thể giải quyết được. Ngoài ra, Tôi đã viết một hướng dẫn đầy đủ nêu chi tiết cách viết một plugin mới cho Knip.
Vẫn còn nhiều chỗ để cải thiện, lỗi cần sửa, tài liệu cần cải thiện và plugin cần thêm! Chúng tôi hoàn toàn hoan nghênh và khuyến khích các ý tưởng và đóng góp của bạn tại github.com/webpro/knip.
Nhiều thứ nhàm chán và lặp đi lặp lại, như định dạng và kiểm tra lỗi, chủ yếu là các vấn đề đã được giải quyết bằng các công cụ như Prettier, ESLint và TypeScript.
Tuy nhiên, có một lĩnh vực khác thường không nhận được nhiều sự chú ý: xử lý các tệp, xuất và phụ thuộc không sử dụng. Điều này đặc biệt đúng khi các dự án phát triển theo thời gian, ảnh hưởng tiêu cực đến khả năng bảo trì cũng như sự nhiệt tình của chúng ta đối với nó. Những hiện vật không sử dụng này thường không được chú ý vì chúng thường khó tìm.
Bạn bắt đầu tìm kiếm những thứ không sử dụng ở đâu? Tôi cá là bạn đã thực hiện tìm kiếm toàn cầu cho một phụ thuộc để tìm hiểu xem nó có còn được sử dụng không. Bạn có biết rằng bạn có thể nhấp chuột phải vào một tệp và "Tìm tham chiếu tệp" trong VS Code không? Đây là những điều bạn không nên phải làm. Chúng là những nhiệm vụ tẻ nhạt có thể — và nên — được tự động hóa.
Phải có một cách tốt hơn
Khi tôi làm việc trong một cơ sở mã đang mở rộng, số lượng tệp và bản xuất không sử dụng trong đó ngày càng tăng. Việc theo dõi chúng ngày càng trở nên khó khăn hơn, vì vậy tôi bắt đầu tìm kiếm các giải pháp tự động để hỗ trợ.Tôi rất vui khi tìm thấy một số công cụ hiện có, chẳng hạn như ts-prune. Sau một số lần chạy ban đầu, tôiphát hiện ra rằng cơ sở mã của chúng tôi yêu cầu rất nhiều cấu hình và vẫn tạo ra nhiều kết quả dương tính giả. Tôi đã nghiên cứu cách các cơ sở mã khác cố gắng duy trì sự gọn gàng và nhận ra rằng có một cơ hội lớn trong không gian này.
Trên đường đi, tôi cũng tìm thấy depcheck, công cụ này xử lý rất nhiều tính phức tạp và tùy chỉnh trong các dự án JavaScript. Và sau đó là unimported, công cụ này cũng thực hiện một công việc đáng chú ý là tìm các tệp tin bị treo và các phụ thuộc chưa sử dụng.
Nhưng không có công cụ nào trong số này xử lý dự án của tôi tốt. Việc tôi phải sử dụng kết hợp các công cụ này sẽ không phải là vấn đề lớn, nhưng tôi không thể cấu hình đúng để xử lý các tùy chỉnh của dự án mà không báo cáo quá nhiều kết quả dương tính giả hoặc bỏ qua quá nhiều nội dung của dự án và để lại một điểm mù lớn.
Cuối cùng, các công cụ trong lĩnh vực này chỉ được sử dụng khi chúng được tự động hóa hoàn toàn và có thể bao quát toàn bộ dự án. Một điều nữa là không có công cụ nào hiện có hỗ trợ monorepos, một cấu trúc cho các kho lưu trữ gần đây đã trở nên phổ biến rộng rãi. Cuối cùng nhưng không kém phần quan trọng, cả ts-prune và depcheck đều ở chế độ bảo trì, nghĩa là chúng có thể sẽ không bao giờ hỗ trợ monorepos.
Làm việc hướng tới giải pháp
Tôi có động lực để tự động hóa mọi thứ và giữ cho các dự án luôn trong tình trạng vững chắc.Vì vậy, tôi bắt đầu phát triển một công cụ nội bộ cho dự án của mình để xem liệu tôi có thể làm tốt hơn không. Nó bắt đầu như một tập lệnh nội bộ chỉ xử lý các chi tiết cụ thể của kho lưu trữ cụ thể đó và trong suốt hành trình, tôi liên tục nhận ra đây vừa là một phước lành vừa là một lời nguyền. Tự động hóa những thứ nhàm chán là một khái niệm chiến thắng, nhưng làm đúng lại là một thách thức khó khăn — nhưng tôi sẵn sàng thử.
Trong quá trình này, tôi cũng ngày càng tin rằng một công cụ duy nhất để tìm tất cả các danh mục những thứ không sử dụng là một ý tưởng hay: mỗi danh mục đều yêu cầu đọc và phân tích các tệp nguồn và vì đây là một nhiệm vụ tương đối tốn kém, tôi nghĩ rằng con đường hiệu quả là theo dõi chúng cùng một lúc.
Giới thiệu về Knip
Vậy, Knip là gì? Tôi nghĩ tốt nhất nên phân loại nó là project linter. Nó tiếp tục từ nơi ESLint kết thúc. Trong khi ESLint xử lý các tệp riêng lẻ, Knip lint toàn bộ kho lưu trữ. Nó kết nối tất cả các điểm — về mặt tệp, nhập, xuất và phụ thuộc — và báo cáo những gì không được sử dụng.Nói một cách đại khái, có hai cách để xem Knip. Trong các dự án mới, thật tuyệt khi cài đặt Knip và để nó phát triển cùng với dự án. Giữ cho kho lưu trữ gọn gàng và chạy Knip theo cách thủ công hoặc trong môi trường tích hợp liên tục (CI) tự động.
Một cách khác để xem xét Knip là trong các dự án lớn hơn. Knip là một người bạn đồng hành tuyệt vời cho việc dọn dẹp khi xác định các tệp, bản xuất và phụ thuộc chưa sử dụng. Có thể có những kết quả dương tính giả ban đầu, nhưng việc bỏ qua chúng dễ hơn nhiều so với việc tự mình mò kim đáy bể.
Ngoài ra, trong hoặc sau những nỗ lực tái cấu trúc lớn, Knip có thể là một trợ lý tuyệt vời để dọn dẹp mọi thứ. Con người thường bỏ lỡ hoặc quên những thứ không còn sử dụng nữa, đặc biệt là khi những thứ đó không gần với công việc tái cấu trúc.
Knip hoạt động với JavaScript truyền thống và TypeScript hiện đại, có hỗ trợ tích hợp cho monorepos, hoạt động với bất kỳ trình quản lý gói nào và có nhiều tính năng, lớn nhỏ, giúp bạn duy trì các dự án của mình.
Knip hoạt động như thế nào
Knip bắt đầu với một hoặc nhiều tệp mục nhập và tính toán cây phụ thuộc, giúp nó biết tất cả các tệp đang được sử dụng trong khi đánh dấu các tệp còn lại là chưa sử dụng.Trong khi đó, Knip theo dõi các phụ thuộc bên ngoài đã nhập và so sánh chúng với các phụ thuộc trong
package.json để báo cáo cả các phụ thuộc chưa sử dụng và các phụ thuộc đã sử dụng nhưng không được liệt kê. Nó cũng theo dõi các lần nhập và xuất nội bộ để báo cáo các lần xuất chưa sử dụng.Để tôi cho bạn cái nhìn sâu hơn về bên trong.
Chế độ sản xuất
Ở chế độ mặc định, Knip phân tích toàn bộ dự án, bao gồm cả các tệp sản xuất và không sản xuất, chẳng hạn như các bài kiểm tra, cấu hình, câu chuyện Storybook,devDependencies, v.v.
Nhưng chế độ này có thể bỏ lỡ cơ hội cắt xén. Ví dụ, các tệp hoặc tệp xuất chỉ được nhập bằng các bài kiểm tra thường không được báo cáo là chưa sử dụng. Tuy nhiên, khi tệp xuất không được sử dụng ở bất kỳ nơi nào khác, bạn có thể xóa cả tệp xuất và các bài kiểm tra của tệp đó!
Đây là lý do tại sao Knip có chế độ sản xuất. Chế độ này nghiêm ngặt hơn chế độ mặc định, trong đó Knip sẽ chỉ sử dụng mã sản xuất làm tệp nhập và chỉ xem xét
phụ thuộc (không bao gồm devDependencies).Scripts
Nhiều dự án sử dụng các công cụ dòng lệnh đi kèm với các phụ thuộc. Ví dụ, sau khi cài đặt ESLint, bạn có thể sử dụngeslint và Angular cung cấp ng trong "scripts" trong package.json. Knip kết nối các phụ thuộc với các tệp nhị phân và cho bạn biết khi chúng không được sử dụng hoặc bị thiếu.Nhưng vẫn còn nhiều hơn thế nữa. Các môi trường CI, như Azure và GitHub Actions, được cấu hình bằng các tệp YAML cũng có thể sử dụng cùng các công cụ dòng lệnh.
Và cuối cùng, các tập lệnh tùy chỉnh có thể sử dụng các công cụ dòng lệnh bằng cách tạo ra các quy trình con, sử dụng API Node.js gốc hoặc với các thư viện như
zx hoặc execa.Knip có số lượng phát hiện như vậy ngày càng tăng để giữ cho các dự án của bạn gọn gàng và ngăn nắp, tái cấu trúc sau tái cấu trúc. Tuy nhiên, điều gì thú vị ở các tập lệnh đó? Chúng có thể phức tạp để phân tích cú pháp, khiến việc trích xuất các phụ thuộc của chúng trở nên khó khăn. Hãy xem một ví dụ:
Mã:
node -r @scope/package/register --experimental-loader ts-node/esm/transpile-only ./dir@scope/package và ts-node và dir/index.ts là các dependency của tập lệnh này. Thành thật mà nói, đây chỉ là phần nổi của tảng băng chìm. Tôi đảm bảo rằng một vài biểu thức chính quy sẽ không đủ!Bây giờ, nếu tập lệnh này được cập nhật hoặc xóa, Knip sẽ cho bạn biết nếu bất kỳ dependency hoặc tệp nào không còn được sử dụng nữa. Mặt khác, Knip cũng sẽ cho bạn biết nếu một dependency được sử dụng nhưng không được liệt kê rõ ràng trong
package.json. (Dù sao thì bạn cũng không nên dựa vào các phụ thuộc bắc cầu, đúng không?)Plugin
Có rất nhiều công cụ có sẵn trong hệ sinh thái JavaScript. Và mỗi công cụ đều có cấu hình riêng. Một số cho phép YAML hoặc JSON, và một số cho phép (hoặc yêu cầu) bạn viết cấu hình trong JavaScript hoặc thậm chí TypeScript.Vì không có cách chung nào để xử lý vô số biến thể, Knip hỗ trợ plugin. Knip có các plugin cho các công cụ có thể tham chiếu đến các phụ thuộc cần được liệt kê trong
package.json.Điều quan trọng đối với plugin là cách tham chiếu các dependency. Chúng có thể được nhập vào JavaScript giống như bất kỳ tệp nguồn nào khác và Knip cũng có thể phân tích cú pháp chúng như vậy. Tuy nhiên, chúng thường được tham chiếu dưới dạng chuỗi, giống như những gì ESLint thực hiện với các tùy chọn
extends và plugins. Các dependency có thể được chỉ định theo cách ngầm định, chẳng hạn như prettier, nghĩa là dependency eslint-config-prettier. Storybook có cấu hình builder: "webpack5" yêu cầu các phụ thuộc @storybook/builder-webpack5 và @storybook/manager-webpack5.Trình biên dịch
Knip phân tích tất cả các loại tệp JavaScript và TypeScript, bao gồm các mô-đun ES và các mô-đun CommonJS.Nhưng một số khung làm việc với các tệp không chuẩn, chẳng hạn như Vue, Svelte, MDX và Astro. Knip cho phép bạn cấu hình trình biên dịch để bao gồm các loại tệp này để chúng cũng có thể được đưa vào phân tích.
Hiệu suất
Cho đến phiên bản 2, Knip đã sử dụng ts-morph để tính toán biểu đồ phụ thuộc (và nhiều hơn nữa). Điều này ban đầu hoạt động rất tốt vì nó trừu tượng hóa phần phụ trợ TypeScript.Nhưng để hỗ trợ monorepos và trình biên dịch trong khi vẫn duy trì hiệu suất tốt, tôi nhận ra rằng mình phải làm việc trực tiếp với phần phụ trợ TypeScript. Điều này đòi hỏi rất nhiều nỗ lực, nhưng nó cung cấp nhiều tính linh hoạt hơn, cũng như các cơ hội để tối ưu hóa nhiều hơn. Ví dụ: Knip chỉ có thể duyệt qua cây cú pháp trừu tượng (AST) của bất kỳ tệp nào một lần để tìm mọi thứ cần thiết.
Gợi ý cấu hình
Khi Knip báo cáo kết quả dương tính giả, bạn có thể định cấu hình để bỏ qua sự phụ thuộc đó. Sau đó, khi Knip không còn báo cáo kết quả dương tính giả nữa, nó sẽ báo cáo rằng cấu hình có thể được cập nhật và bạn có thể xóa các mục bị bỏ qua.Reporters
Knip đi kèm với một trình báo cáo mặc định và có một số trình báo cáo bổ sung. Có một trình báo cáo nhỏ gọn, một trình báo cáo JSON và một trình báo cáo sử dụng tệpCODEOWNERS để hiển thị chủ sở hữu mã với mỗi sự cố được báo cáo.Knip cũng cho phép bạn xác định một trình báo cáo tùy chỉnh. Knip sẽ gọi hàm của bạn với kết quả phân tích. Sau đó, bạn có thể làm bất cứ điều gì với nó, như ghi kết quả vào tệp hoặc gửi đến dịch vụ để theo dõi tiến trình theo thời gian.
Knip sẽ làm gì tiếp theo?
Tất nhiên, tôi vẫn chưa hoàn thành công việc trên Knip. Đây là một số điều tôi nghĩ đến.Nhiều Plugin hơn = Ít Cấu hình hơn
Tôi hy vọng với Knip là khi ngày càng nhiều người bắt đầu sử dụng Knip, họ sẽ báo cáo các kết quả dương tính giả: một thứ gì đó được báo cáo là chưa sử dụng nhưng thực tế là đang được sử dụng.Một kết quả dương tính giả thường có một trong ba nguyên nhân sau:
- Một khuôn khổ hoặc công cụ được sử dụng mà Knip chưa có plugin cho,
- Cấu hình có thể cần cải thiện; ví dụ, thêm một tệp mục nhập mà Knip không biết hoặc bỏ qua thứ gì đó có tham chiếu khó tìm hoặc
- Knip có lỗi.
Khi bạn đang sử dụng Knip và thích thú với nó, đừng để các kết quả dương tính giả làm bạn sợ mà hãy báo cáo chúng. Vui lòng cung cấp một trường hợp kiểm tra có thể tái tạo được và tôi chắc chắn chúng ta có thể giải quyết được. Ngoài ra, Tôi đã viết một hướng dẫn đầy đủ nêu chi tiết cách viết một plugin mới cho Knip.
Tự động sửa
Giống như ESLint, Knip sẽ có tùy chọn--fix để tự động sửa mọi loại sự cố. Ý tưởng là điều này có thể tự động xử lý những việc như sau:- Xóa từ khóa
exportcho các bản xuất không sử dụng, - Gỡ cài đặt các phụ thuộc không sử dụng và cài đặt các phụ thuộc không được liệt kê và
- Xóa các tệp không sử dụng.
Tích hợp
Các tích hợp như plugin VS Code hoặc GitHub Action nghe có vẻ là những cơ hội tuyệt vời. Tôi rất vui khi được hợp tác và xem chúng ta có thể đưa nó đến đâu.Demo Knip
Tôi nghĩ cách tốt nhất để hiểu Knip là tự mình trải nghiệm. Vì vậy, tôi đã tạo một mẫu CodeSandbox mà bạn có thể fork và chạy Knip trong một terminal mới bằngnpm run knip.Kết luận
Knip hướng đến mục tiêu giúp bạn duy trì kho lưu trữ JavaScript hoặc TypeScript của mình và tôi rất vui khi thấy Knip đã cắt rất nhiều dự án hàng ngày.Vẫn còn nhiều chỗ để cải thiện, lỗi cần sửa, tài liệu cần cải thiện và plugin cần thêm! Chúng tôi hoàn toàn hoan nghênh và khuyến khích các ý tưởng và đóng góp của bạn tại github.com/webpro/knip.
