Prettier: công cụ định dạng mã có chủ kiến cho nhóm phát triển web nhỏ
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
Prettier cho nhóm nhỏ: chấm dứt tranh cãi về dấu ngoặc, giữ lại thời gian cho việc khác
Prettier là công cụ định dạng mã nguồn (code formatter) có chủ kiến: nó phân tích cú pháp mã, rồi in lại theo bộ quy tắc riêng có tính đến độ dài dòng tối đa, thay vì giữ nguyên cách người viết đã gõ. Trang giới thiệu liệt kê các ngôn ngữ được hỗ trợ sẵn như JavaScript, TypeScript, Flow, JSX, JSON, CSS, SCSS, Less, HTML, Vue, Angular, GraphQL, Markdown và YAML. [1]
Lý do chính để cân nhắc là tính nhất quán. README mô tả có thể chạy Prettier trong trình soạn thảo khi lưu tệp, trong pre-commit hook hoặc trong môi trường CI để cả nhóm có cùng một kiểu trình bày mà không cần góp ý chuyện vặt khi review. [1] Với đội phần mềm vài người, đây là khoản đầu tư nhỏ vì công cụ chỉ chạy trên máy lập trình và trong CI.
Không nên kỳ vọng Prettier làm nhiều hơn việc trình bày. Tài liệu lý giải của dự án nói rõ nó chỉ in mã, không biến đổi mã, nên không sắp xếp import, không đổi cấu trúc điều kiện, không thay thế công cụ kiểm tra lỗi logic. [4] Nếu nhóm đang cần phát hiện lỗi hoặc ép quy ước đặt tên, hãy đi cùng một công cụ lint; nếu nhóm muốn tùy biến từng chi tiết trình bày theo sở thích riêng, Prettier cố ý không phục vụ nhu cầu đó. [5]
Cuộc tranh luận về khoảng trắng tiêu tốn bao nhiêu sự chú ý của một nhóm?
Trong một nhóm phát triển, những bất đồng nhỏ về dấu chấm phẩy, dấu nháy hay cách xuống dòng thường quay lại trong từng lượt review. Đội dự án Prettier xác định mục tiêu lớn nhất khi dùng công cụ này là chấm dứt các cuộc tranh luận về phong cách, và trích lại câu đó ngay trong trang triết lý về tùy chọn. [5] Điểm đáng chú ý là họ coi việc có nhiều tùy chọn là mối nguy, vì tranh luận về phong cách có thể biến thành tranh luận xem nên bật tùy chọn nào.
Vấn đề thứ hai là nhiễu trong lịch sử thay đổi: khi mỗi người định dạng theo thói quen riêng, người duyệt khó nhìn ra phần thay đổi thật. Đây là lập luận phân tích; nguồn không cung cấp số liệu về mức giảm thời gian review.
Prettier xử lý vấn đề bằng cách đặt một quyết định tập trung: đầu vào là mã hợp lệ, đầu ra là mã trình bày theo cùng bộ quy tắc, bất kể ai gõ. Tài liệu lý giải nêu yêu cầu đầu tiên là đầu ra phải hợp lệ và giữ nguyên hành vi như trước khi định dạng, và coi mọi trường hợp vi phạm là lỗi cần báo. [4]
Từ cây cú pháp đến chuỗi ký tự: ba tầng parser, printer và Doc
Cấu trúc của Prettier xoay quanh ba khái niệm mà tài liệu về plugin mô tả khá rõ. Parser chuyển chuỗi mã thành cây cú pháp trừu tượng (AST). Printer nhận AST và trả về một biểu diễn trung gian gọi là Doc. Cuối cùng Prettier biến Doc thành chuỗi ký tự dựa trên các tùy chọn như độ rộng dòng. [7]
Điều này giải thích vì sao ngôn ngữ mới được thêm vào theo cách thống nhất. Tài liệu plugin cho biết cách cài đặt hỗ trợ ngôn ngữ của chính Prettier cũng được diễn đạt qua API plugin, còn gói lõi đã tích hợp sẵn JavaScript và các ngôn ngữ thiên về web; những ngôn ngữ khác cần cài plugin. [7] Một plugin phải khai báo danh sách ngôn ngữ, parser và printer; khóa của parser phải khớp tên trong khai báo ngôn ngữ, khóa của printer phải khớp tên định dạng AST mà parser tạo ra. [7]
Quy trình in gồm các bước: tiền xử lý AST (tùy chọn), gắn chú thích vào nút phù hợp, xử lý ngôn ngữ nhúng như CSS-in-JS rồi in đệ quy ra Doc. [7] Tài liệu lý giải thừa nhận việc đặt chú thích đúng chỗ là vấn đề khó và Prettier chỉ cố giữ chúng gần vị trí cũ. [4] Trong các tài liệu đã đọc không có thành phần máy chủ hay cơ sở dữ liệu nào.
Một tệp đi qua Prettier: tìm cấu hình, chọn parser, in lại, ghi đè
Luồng xử lý một tệp bắt đầu từ việc xác định cấu hình. Tài liệu cấu hình nêu thứ tự ưu tiên: khóa prettier trong package.json hoặc package.yaml, rồi tệp .prettierrc dạng JSON hoặc YAML, các biến thể .prettierrc.json, .yml, .json5, tệp JavaScript hoặc TypeScript như prettier.config.mjs, và tệp .prettierrc.toml. Cấu hình được tìm từ vị trí của tệp đang định dạng, đi ngược lên cây thư mục cho tới khi gặp hoặc không gặp tệp cấu hình. [8]
Tiếp theo là chọn parser. Mặc định Prettier suy ra parser từ đuôi tệp, và có thể dạy nó xử lý tệp lạ bằng mục overrides. Tài liệu cảnh báo đừng đặt tùy chọn parser ở cấp cao nhất vì sẽ ép mọi loại tệp dùng cùng một parser, chẳng hạn bắt tệp CSS phải đọc như JavaScript. [8] Tệp .editorconfig, nếu có, cũng được chuyển thành cấu hình và bị .prettierrc ghi đè. [8]
Sau cùng là bước in và ghi kết quả; nhóm có thể kiểm soát điểm này bằng lệnh khác nhau tùy mục đích. README nêu việc chạy trong môi trường CI, còn trang CI của tài liệu minh họa lệnh ghi đè với tùy chọn write rồi để một workflow đẩy bản sửa tự động. [1][6] Nhóm nên chốt từ đầu là CI chỉ báo lỗi hay tự sửa.
Những gì tài liệu xác nhận Prettier làm được
Về phạm vi ngôn ngữ, README liệt kê danh sách trên và dẫn tới trang plugin cho ngôn ngữ khác. [1] Trang plugin nêu bốn plugin chính thức cho PHP, Pug, Ruby và XML, đồng thời có danh mục plugin cộng đồng. [7] Mỗi plugin cần được cân nhắc riêng.
Về cấu hình, ngoài nhiều định dạng tệp, Prettier hỗ trợ overrides theo mẫu đường dẫn: mẫu được so với đường dẫn tương đối với thư mục chứa tệp cấu hình, nên một mẫu như legacy/**/*.js chỉ áp dụng cho thư mục legacy cạnh tệp đó, còn mẫu không có dấu gạch chéo được so với tên tệp ở mọi độ sâu. [8] Tệp cấu hình TypeScript cần Node.js từ 22.6.0 trở lên. [8] Prettier cố ý không hỗ trợ cấu hình toàn cục. [8]
Về hành vi định dạng, tài liệu lý giải mô tả nhiều quy tắc cụ thể: chọn kiểu dấu nháy ít phải escape nhất, gộp nhiều dòng trống thành một, giữ nguyên cách escape của chuỗi, và coi độ rộng dòng như chỉ dẫn chứ không phải giới hạn cứng. [4] Với các tệp do máy sinh như package.json, Prettier dùng bộ định dạng dựa trên JSON.stringify để tránh xung đột với công cụ quản lý gói. [4]
Những điều Prettier cố ý không làm, và vì sao đó là ưu điểm
Có thể tóm tắt triết lý của Prettier thành một câu: chỉ in, không biến đổi. Tài liệu lý giải liệt kê các việc nằm ngoài phạm vi, như đổi chuỗi sang template literal, thêm hoặc bỏ dấu ngoặc nhọn và return tùy chọn, đổi toán tử ba ngôi thành if-else, hoặc sắp xếp import và khóa đối tượng. Lý do được nêu là sắp xếp có thể không an toàn do tác dụng phụ và làm khó việc kiểm chứng mục tiêu đúng đắn. [4]
Tương tự, trang triết lý tùy chọn tuyên bố các tùy chọn trình bày hiện có là di sản lịch sử và dự án không nhận thêm yêu cầu tùy chọn mới; yêu cầu giữ nguyên một phần định dạng đầu vào cũng bị coi là tùy chọn trá hình. [5] Vì vậy không nên chọn Prettier với hy vọng sẽ có công tắc cho sở thích riêng của đội.
Tài liệu lý giải còn thừa nhận một vài chỗ chưa lý tưởng. Với đối tượng nhiều dòng, Prettier giữ trạng thái đa dòng nếu có xuống dòng ngay sau dấu mở, và chính nhóm gọi đó là giải pháp tạm chứ không phải tính năng. [4] Cú pháp không chuẩn như đề xuất ECMAScript giai đoạn đầu được hỗ trợ theo hướng cố gắng và thử nghiệm; tương thích có thể thay đổi giữa các bản phát hành mà không bị coi là thay đổi phá vỡ. [4]
Ai nên dùng, ai nên bỏ qua
Nhóm phù hợp nhất là những đội có nhiều người cùng chạm vào một kho mã giao diện web: lập trình viên nội bộ, agency thiết kế web, và nhà cung cấp phần mềm phải bàn giao mã cho khách. Phạm vi ngôn ngữ trong README trùng với những gì một website hiện đại thường chứa: HTML, CSS, JavaScript, TypeScript, JSON, Markdown, YAML. [1]
Nhóm thứ hai là người quản trị tài liệu kỹ thuật viết bằng Markdown hoặc YAML; README liệt kê cả hai định dạng. [1] Hành vi với Markdown nên được thử trên bộ tài liệu thật trước khi bật trong CI.
Không phù hợp với đội muốn công cụ tự sửa lỗi logic hoặc ép quy ước đặt tên, và không phù hợp nếu tổ chức đòi quyền tùy chỉnh trình bày chi tiết. [4][5] Prettier cũng không phải biện pháp bảo mật.
Tình huống giả định: kho mã trang đặt lịch của chuỗi phòng khám nha khoa tư nhân
Đây là một đề xuất ứng dụng, không phải trường hợp đã triển khai. Giả sử một phòng khám nha khoa tư nhân ở TP.HCM có website giới thiệu dịch vụ, trang đặt lịch hẹn và vài biểu mẫu thu thập thông tin trước khi khám. Mã nguồn do một lập trình viên nội bộ cùng hai đối tác thuê ngoài thay phiên chỉnh sửa theo từng chiến dịch như niềng răng, bọc sứ, khuyến mãi cuối năm. Mỗi người dùng một soạn thảo khác nhau.
Đề xuất là đưa Prettier vào kho mã theo ba bước. Thứ nhất, ghim một phiên bản cụ thể trong dự án và đặt một tệp cấu hình duy nhất ở thư mục gốc; tài liệu CI cũng yêu cầu bản Prettier được ghim khi dùng workflow tự sửa. [6][8] Thứ hai, bật định dạng khi lưu và pre-commit hook, theo cách README mô tả. [1] Thứ ba, thêm một job CI kiểm tra để từ chối các thay đổi không đúng định dạng. Lần chuyển đổi đầu tiên nên nằm trong một commit riêng.
Lợi ích kỳ vọng nằm ở bàn giao và rà soát: đối tác mới mở kho mã sẽ gặp một kiểu trình bày duy nhất, người duyệt chỉ cần đọc phần logic như chính sách giữ dữ liệu bệnh nhân hay luồng gửi biểu mẫu. Đó là kỳ vọng, cần đo trong giai đoạn thử nghiệm. Văn bản y khoa do bác sĩ duyệt cần được kiểm tra lại sau khi định dạng, và dữ liệu bệnh nhân không nên nằm trong kho mã.
Triển khai và vận hành: ghim phiên bản, một tệp cấu hình, một nguồn sự thật
Vận hành Prettier chủ yếu là quản lý phiên bản và cấu hình. Tài liệu CI nhấn mạnh phải cài bản Prettier đã ghim trong kho mã khi dùng workflow tự sửa, và ví dụ chạy lệnh ghi đè trong GitHub Actions rồi để ứng dụng autofix.ci đẩy commit sửa. [6] Đây là một dịch vụ bên thứ ba cần được đánh giá riêng về quyền truy cập, không phải phần của Prettier.
Tệp cấu hình cần được đặt trong kho để mọi máy dùng chung vì Prettier không có cấu hình toàn cục theo thiết kế. [8] Nhóm nên chọn một định dạng cấu hình duy nhất, vì tài liệu liệt kê rất nhiều tên tệp hợp lệ và có thứ tự ưu tiên giữa chúng; để nhiều tệp cùng tồn tại dễ gây nhầm lẫn khi gỡ lỗi. [8]
Về nâng cấp, tài liệu lý giải nói rõ hỗ trợ cú pháp thử nghiệm có thể đổi trong bất kỳ bản phát hành nào. [4] Do đó mỗi lần nâng cấp nên chạy trên toàn kho mã trong một nhánh riêng và xem phần chênh lệch trước khi gộp.
Bảo mật và quyền riêng tư: bề mặt nhỏ nhưng có plugin và tệp cấu hình thực thi
Prettier chạy cục bộ trên mã nguồn và các nguồn đã đọc không mô tả việc gửi mã ra dịch vụ nào của dự án. Chính sách bảo mật ngắn của dự án hướng người báo lỗ hổng tới liên hệ bảo mật của Tidelift. [3] Tệp chính sách chỉ có đoạn đó nên không thể nói thêm về quy trình xử lý.
Điểm cần thận trọng thực tế đến từ khả năng mở rộng. Tệp cấu hình có thể là JavaScript hoặc TypeScript xuất ra đối tượng, và chuỗi trong tùy chọn plugins cuối cùng được truyền cho biểu thức import(), nên có thể là tên gói, đường dẫn hoặc bất cứ thứ gì import chấp nhận. [7][8] Hệ quả đề xuất: coi tệp cấu hình và plugin như mã thực thi, chỉ chấp nhận plugin từ nguồn đã rà soát, và không chạy Prettier với cấu hình lấy từ nguồn không tin cậy trong CI có quyền cao.
Với workflow tự sửa, ví dụ trong tài liệu đặt permissions là rỗng cho job, một dấu hiệu tốt về nguyên tắc quyền tối thiểu, nhưng việc đẩy commit nằm ở ứng dụng bên thứ ba. [6] Nhóm nên cân nhắc chỉ kiểm tra trong CI và để lập trình viên tự sửa cục bộ nếu không muốn cấp thêm quyền ghi cho dịch vụ ngoài.
Giấy phép MIT và những gì nó không bao phủ
Tệp LICENSE tại commit khảo sát là giấy phép MIT với dòng bản quyền James Long và những người đóng góp. Văn bản cho phép sử dụng, sao chép, sửa đổi, hợp nhất, xuất bản, phân phối và cấp phép lại phần mềm, với điều kiện giữ nguyên thông báo bản quyền và thông báo cấp phép; phần mềm được cung cấp nguyên trạng, không bảo hành. [2]
Trong các nguồn đã đọc không có tệp giấy phép bổ sung hay cấu trúc lõi mở cộng bản thương mại. Dù vậy, giấy phép này chỉ áp dụng cho mã của Prettier tại commit khảo sát. Plugin của bên thứ ba, phần phụ thuộc, dịch vụ như autofix.ci, và mã của chính khách hàng được định dạng đều có điều khoản riêng cần kiểm tra. [2][6][7]
README có phần huy hiệu cho phép dự án dùng Prettier gắn nhãn code style; đó là đề nghị của dự án chứ không phải điều kiện giấy phép. [1][2] Nếu cần dùng tên hoặc logo trong tài liệu thương mại, nên hỏi ý kiến pháp chế vì các nguồn đã đọc không nêu chính sách nhãn hiệu.
Chi phí và nguồn lực: chủ yếu là thời gian chuyển đổi
Phần mềm không thu phí giấy phép theo văn bản MIT, nên chi phí nằm ở nhân lực và quy trình. [2] Loại nguồn lực cần có gồm thời gian một lập trình viên viết cấu hình và pre-commit hook, thời gian rà soát lần định dạng hàng loạt đầu tiên, và một lượng nhỏ phút CI cho mỗi lần chạy kiểm tra. Bài viết không đưa số giờ hay số tiền cụ thể vì không có nguồn đáng tin cho quy mô kho mã của từng đơn vị.
Chi phí ẩn là sự không đồng thuận ban đầu. Vì Prettier không nhận thêm tùy chọn trình bày, sẽ có người không hài lòng với một số lựa chọn mặc định, và nhóm cần quyết định chấp nhận thay vì tiếp tục tranh luận. [5]
Giả định: kho mã đã có Node.js trong quy trình build, nhóm dùng Git và có CI; nếu chưa, cần tính thêm. Máy chủ chuyên dụng hay GPU không được nhắc tới trong nguồn đã đọc.
So sánh phương án: formatter có chủ kiến, quy tắc lint tự sửa hay tự thỏa thuận
Có ít nhất ba hướng tiếp cận. Hướng một là thỏa thuận quy ước bằng văn bản và dựa vào review, rẻ về công cụ nhưng tốn sự chú ý của con người. Hướng hai là dùng linter có quy tắc định dạng tự sửa, cho phép tùy chỉnh sâu hơn nhưng dễ quay lại cuộc tranh luận về từng quy tắc. Hướng ba là dùng formatter có chủ kiến như Prettier, hy sinh quyền tùy biến để lấy sự nhất quán.
Tài liệu của Prettier tự đặt mình ở hướng ba: chỉ in mã, không biến đổi, và không mở thêm tùy chọn trình bày. [4][5] Cây tài liệu có trang so sánh và trang tích hợp với linter nhưng chúng tôi chưa đọc, nên không nhận xét về công cụ cụ thể khác.
Tiêu chí chọn đề xuất: nếu ưu tiên hàng đầu là giảm tranh luận và có nhiều người đóng góp, Prettier phù hợp; nếu cần quy tắc riêng mà dự án đã có chuẩn nội bộ chặt, cần đánh giá khả năng chấp nhận mất một số tùy biến. Quyết định nên dựa trên thử nghiệm trên kho mã thật.
Hạn chế và điều kiện không nên dùng
Hạn chế đầu tiên là tính áp đặt. Dự án tuyên bố không nhận thêm tùy chọn định dạng và đóng yêu cầu như vậy mà không thảo luận. [5] Đội cần quy ước trình bày khác với mặc định sẽ phải chấp nhận hoặc chọn công cụ khác.
Thứ hai, một số hành vi mang tính thực dụng hơn là nguyên tắc: tài liệu thừa nhận cách xử lý đối tượng đa dòng và decorator là giải pháp tạm thời hoặc chưa lý tưởng. [4] Thứ ba, tệp rất dài hoặc cấu trúc lồng sâu có thể vượt độ rộng dòng, vì độ rộng chỉ là hướng dẫn. [4]
Không nên dùng Prettier làm cổng chặn cho tệp do máy sinh mà không thử trước, vì tài liệu có quy tắc riêng cho các tệp như package.json. [4] Cũng không nên cho phép plugin hoặc cấu hình từ nguồn không đáng tin chạy trong môi trường có bí mật. [7][8] Hiệu năng trên kho mã rất lớn chưa được nguồn đã đọc đề cập, nên cần đo thực tế.
Kế hoạch thử nghiệm bốn tuần cho kho mã trang đặt lịch
Giai đoạn một, tuần đầu: chọn một kho mã, ghim phiên bản, viết tệp cấu hình duy nhất, chạy trên một nhánh thử và ghi số tệp thay đổi. Tiêu chí thoát: hành vi của website không đổi theo bộ kiểm tra thủ công đã thống nhất, vì mục tiêu đầu tiên của Prettier là giữ nguyên hành vi. [4]
Giai đoạn hai, tuần hai: bật định dạng khi lưu và pre-commit hook cho toàn bộ người đóng góp, kể cả đối tác thuê ngoài. Đo số lần hook thất bại do môi trường. Tiêu chí: mọi người đóng góp chạy được, mỗi người cần hỗ trợ trực tiếp không quá một lần.
Giai đoạn ba, tuần ba: thêm job CI kiểm tra định dạng. Theo dõi số pull request bị chặn và thời gian job chạy. Tiêu chí: job ổn định; nếu cân nhắc workflow tự sửa thì đánh giá quyền của dịch vụ ngoài trước. [6]
Giai đoạn bốn, tuần bốn: so sánh số dòng chỉ khác khoảng trắng trong các pull request trước và sau thử nghiệm, cùng ý kiến người duyệt. Tiêu chí dừng: không đạt đồng thuận về cấu hình hoặc xuất hiện lỗi làm thay đổi hành vi thì tạm hoãn.
Kết luận: đáng thử khi mục tiêu là nhất quán, không phải tùy biến
Prettier là công cụ có phạm vi hẹp và được mô tả rõ trong tài liệu của chính dự án: in lại mã theo một bộ quy tắc có chủ kiến, hỗ trợ nhiều ngôn ngữ web, chạy cục bộ hoặc trong CI. [1][4] Giấy phép MIT dễ chấp nhận và tùy chọn được chốt ổn định. [2][5]
Khuyến nghị cho tình huống phòng khám nha khoa giả định là thử nghiệm bốn tuần trên một kho mã duy nhất, coi tệp cấu hình và plugin như mã thực thi, và ghim phiên bản. Chỉ mở rộng khi các tiêu chí đo được ở trên đạt. Với các đơn vị đang xây hệ thống tri thức nội bộ, chẳng hạn kho ghi chú Markdown như cách phamvanthu.com hoặc hệ sinh thái BDSG có thể cân nhắc, cùng một cấu hình có thể giúp tài liệu và mã giữ cùng chuẩn trình bày; đây là gợi ý ứng dụng, không phải khẳng định BDSG đang dùng công cụ này.
Nguồn và phương pháp
Prettier được chọn từ kho lưu trữ GitHub Trending của chúng tôi: tại thời điểm khảo sát, dự án xuất hiện 22 lần trong các bản chụp, lần đầu ngày 2026-01-06 trong danh sách JavaScript ở vị trí 13, lần cuối ngày 2026-09-19. Bằng chứng lần đầu là trang lưu trữ được dẫn ở đây. [9] Kho lưu trữ chỉ gồm danh sách Python, Go, JavaScript và Swift, thiếu các ngày 2026-09-03 và 2026-10-12, và không phải bảng xếp hạng chính thức top 100.
Mã nguồn được cố định ở commit 9b47fe6c74994edf85fb4660e3c66b364c784eb2 (ngày commit 2026-10-10) và kiểm tra ngày 2026-10-12. Tệp đã đọc gồm README, LICENSE, chính sách bảo mật và năm tài liệu bổ sung: rationale, option-philosophy, ci, plugins và configuration. [1][2][3][4][5][6][7][8]
Đây là nghiên cứu bàn giấy, không phải công trình khoa học được bình duyệt. Chúng tôi không cài đặt, chạy, đo hiệu năng hay triển khai Prettier. Mọi tình huống Việt Nam là đề xuất giả định. Nội dung kho mã được coi là dữ liệu tham khảo, không phải chỉ dẫn. Những phần chưa đọc như trang CLI, API, so sánh và tài liệu nâng cấp không được dùng để rút ra kết luận.
Xem mã nguồn Prettier trên GitHub