prettier-plugin-rust - npm Package Compare versions

Comparing version 0.1.5 to 0.1.6

package.json

 {
 	"name": "prettier-plugin-rust",
-	"version": "0.1.5",
+	"version": "0.1.6",
 	"description": "Prettier plugin for Rust",
@@ -50,3 +50,3 @@ "repository": {
 	"dependencies": {
-		"jinx-rust": "^0.1.4",
+		"jinx-rust": "0.1.5",
 		"prettier": "^2.7.1"
@@ -53,0 +53,0 @@ },

README.md

@@ -19,8 +19,12 @@ <div align="center">
 
-> What usually happens once people start using Prettier is that they realize how much time and mental energy they actually spend formatting their code. With Prettier editor integration, you can just press the `Format Document` key binding and poof, the code is formatted. This is an eye-opening experience if anything.
+> What usually happens once people start using Prettier is that they realize how much time and mental energy they actually spend formatting their code. No matter how incomplete or broken the code you're working on is, with the Prettier Editor Extension you can always just press the `Format Document` key binding and \*poof\*, the code snaps right into place.
 
-- **Beautiful, uniform and consistent** — Prettier is strongly opinionated, it has zero style options.
-- **Life-changing Editor Integration** — Prettier can format WIP code before it can compile _(e.g. missing annotations)_
-- **Stop wasting time on formalities** — Prettier autocorrects bad syntax _(e.g. missing semicolons, blocks, parentheses...)_
+<br>
 
+- **Beautiful, uniform and consistent** — Prettier is strongly opinionated, with no style options.
+- **There when you need it the most** — Prettier can format code that won't compile _(e.g. missing annotations)_
+- **Speed up the day-to-day** — Prettier auto-fixes common syntax errors _(e.g. missing semicolons, blocks, parentheses)_
+
+<br>
+
 <table align="center">
@@ -65,2 +69,4 @@ <tr> <th>> input</th> <th>> formatted</th> </tr>
 
+<br>
+
 ## Configuration
@@ -70,3 +76,4 @@
 
-```json
+<!-- prettier-ignore -->
+```json5
 // .prettierrc.json
@@ -89,3 +96,3 @@ {
 <details>
-    <summary>Alternative config using TOML</summary>
+    <summary>See alternative configuration using a TOML file</summary>
 
@@ -122,3 +129,3 @@ ```toml
 - Formatting inside macro invocations is more conservative, since macros can be token-sensitive
-- Popular/built-in macros with original syntax rules get custom formatting (e.g. `matches!`, `if_chains!`...)
+- Popular/built-in macros with original syntax rules get custom formatting (e.g. `matches!`, `if_chains!`...) _[Not implemented yet]_
 - Macro Declarations are only partially formatted (the transformed part isn't yet, but could be in the future)
@@ -131,2 +138,4 @@ - Macros that can't be formatted are silently ignored
 
+<br>
+
 ## Editor integration
@@ -155,2 +164,4 @@
 
+<br>
+
 ## Project integration
@@ -200,3 +211,3 @@
 
----
+<br>
 
@@ -207,21 +218,38 @@ ## Q&A
 
-  **It mostly comes down to the Editor Integration.** — With Prettier Rust, you have the ability to hit the `Format Document` keybind on incomplete code and everything fits right into place. Again reiterating on what was said in the introduction, but this is _actually_ life-changing. Just try it out, 1-click install the extension, write a few lines and hit the keybind.
+  _It's all about the Editor Integration_ — Having the ability to format your code while you work on it really makes for a great developer experience, and autocompletion for Rust's strict syntax is such a massive time save. Once you've tried the extension there really is no coming back.
 
-   There's only little difference in terms of how code is printed, so adopting Prettier Rust won't drastically change a codebase. Prettier's only downside against Rustfmt is its troublesome integration into the Rust ecosystem. Fortunately it's only a matter of time before it gets resolved.
+  All-in-all the difference in code style is minimal, so adopting Prettier Rust won't drastically change your codebase. The real downside is the harsher integration with the Rust ecosystem, but it'll get better eventually.
 
-  See also:
+  Point by point:
 
-  - Prettier Rust does not have style options.
-  - Prettier Rust produces slightly more readable code (e.g. parenthesis around compound bin ops)
-  - Prettier Rust supports more things by default (nightly features, macros, ...)
-  - Prettier consistently prints code in the same way, whereas rustfmt preserves arbitrary style at places
-  - Prettier is available for many languages (e.g. markdown, html, typescript, java, python, ruby...)
-  - Prettier supports language embeds. It formats rust code blocks in non-rust files (e.g. markdown), and conversely formats supported languages within rust doc comments.
+  - the extension streamlines your work in the editor
+    - it can format code that won't compile _(e.g. code with missing type annotations)_
+    - it autocorrects syntax errors _(e.g. missing semicolons, blocks, parentheses...)_
+  - it is strongly opinionated with no style options, so code is uniform across projects.
+  - it produces more readable code in some cases (e.g. condition chains, compound expressions, patterns)
+  - it supports everything out-of-the-box (e.g. nightly features, macros)
+  - it consistently prints code in the same way, whereas Rustfmt preserves arbitrary style at places
+  - it can be used for other languages (e.g. markdown, html, typescript, java, python, ruby)
+  - it formats language embeds. So rust code blocks in non-rust files (e.g. markdown), and supported languages in rust doc comments. _[NOTE: the latter is not yet implemented]_
 
-- ### _How can Prettier Rust format files that the Rust Compiler cannot parse?_
+- ### _Why not just add those features to rustfmt instead?_
 
-  Prettier Rust is based on `jinx-rust`, a Rust Parser specially built for Rust Tooling. [Learn more about jinx-rust here.](https://github.com/jinxdash/jinx-rust)
+  Unfortunately Rustfmt cannot implement those features by design.
 
-- ### _How does Prettier Rust compare to Prettier Typescript?_
+  Rustfmt parses code with rustc. Rustc is strict and unforgiving as it always assumes code is at its "final version", thus every slight deviation from the accepted syntax crashes the parser. There's also that rustc has many lint-like checks within the parser. The intention is to save work for the compiler down the line, unfortunately it also means that rustc sometimes fails to parse syntactically correct code.
 
-  Prettier Rust is essentially a port of Prettier Typescript. The Rust plugin barely introduces style opinions on its own.
+  Prettier Rust however is based on [jinx-rust](https://github.com/jinxdash/jinx-rust). Jinx-rust is built specifically for Rust tooling. Hence it's designed to tolerate a wide range of syntax errors, supports missing nodes and sometimes even infers user intent (e.g. Javascript's `!==`)
+
+  Jinx-rust has a little *plaidoyer* in its readme arguing for Rust Tooling *not* to use the official rustc parser [here](https://github.com/jinxdash/jinx-rust#why-jinx-rust-and-why-in-typescript).
+
+- ### _When exactly does Prettier Rust change code syntax?_
+
+  The Prettier Rust syntax autocorrection feature is intended to be an adaptation of how Prettier Typescript autocorrects javascript code with missing semicolons.
+
+  You can effectively think of Prettier Rust syntax autocorrection as auto-applying the Rust compiler's suggested syntax fixes automatically (e.g. "semicolon missing here", "parenthesize this" or "add a block around that")
+
+  Otherwise if your codebase compiles, then Prettier Rust is just a formatter like any other. It won't change the syntax of valid rust code. Moreover, it doesn't reorganize imports, split comments or combine attributes.
+
+- ### _This is an "opinionated formatter". But it's brand new! How reliable are those opinions?_
+
+  Rest assured, Prettier Rust actually does not take style decisions on its own. Prettier Rust is essentially a 1:1 adaptation of Prettier Typescript, hence the opinions it implements have been battle tested and agreed-upon by [millions and millions of users](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) already.

No alert changes

Improved metrics

Total package byte prevSize

329494

increased by0.6%

Number of lines in readme file

247

increased by13.3%

Worsened metrics

Lines of code

8072

decreased by-0.07%

Dependency changes

• + Addedjinx-rust@0.1.5(transitive)

• - Removedjinx-rust@0.1.6(transitive)

• Updatedjinx-rust@0.1.5