feat(rome_js_formatter): 💡 Prettier Compatibility Metric

[IWANABETHATGUY]

Summary

part of #2555

Test Plan

[MichaReiser]

Would you mind creating a Gist and sharing the link of the gist as part of your test plan?

[IWANABETHATGUY]

Would you mind creating a Gist and sharing the link of the gist as part of your test plan?

no, of course

[IWANABETHATGUY]

https://gist.github.com/IWANABETHATGUY/41aabdecaa01e684a2ce8e9edd6ee4f2, added here.

[IWANABETHATGUY]

https://gist.github.com/IWANABETHATGUY/309ab36a9e51bb3748e8e936432b2ac1, what about this?

[MichaReiser]

Looks good. I've a few suggestions regarding the formatting and naming of the metrics.

[IWANABETHATGUY]

https://gist.github.com/IWANABETHATGUY/d67c100cb7dc5c274a497bfb0d16aa68

[MichaReiser]

Awesome. This is getting sooo good!

I find the

File Based Average Prettier Similarity: 69.29%
Line Based Average Prettier Similarity: 64.28%

hard to understand. Which is why I would opt for Prettier similarity for the "line based" and Average prettier similarity for the file based.

I think these terms are more intuitive because the common definition of an average is that you take the value for each file and divide it by the number of files, which is exactly how the metric is defined.

The total Prettier Similarity metric then remains a bit more obscure but that's already the case with the per file on which is why I believe that's fine.

I think it would help to either:

• Include a link to the issue in the report where people can look up the metric definition
• Or include the metric definitions in the report.

[IWANABETHATGUY]

Awesome. This is getting sooo good!

I find the

File Based Average Prettier Similarity: 69.29%
Line Based Average Prettier Similarity: 64.28%

hard to understand. Which is why I would opt for Prettier similarity for the "line based" and Average prettier similarity for the file based.

I think these terms are more intuitive because the common definition of an average is that you take the value for each file and divide it by the number of files, which is exactly how the metric is defined.

The total Prettier Similarity metric then remains a bit more obscure but that's already the case with the per file on which is why I believe that's fine.

I think it would help to either:

• Include a link to the issue in the report where people can look up the metric definition
• Or include the metric definitions in the report.

https://gist.github.com/IWANABETHATGUY/148d1c973aa3e5b604159b6f5890d538

[IWANABETHATGUY]

@NicholasLYang , It seems our Ci has failed due to crates/website/playgroud/lib.rs, would you mind making a pull request to fix it?

[MichaReiser]

Awesome. Thank you. This metric will help me a lot when refactoring some of the printer behaviour to track if the changes are improving compatibility or not.

Are you interested in tackling the CI integration (writing the information to a JSON file and having a command to compare the results) next?

[IWANABETHATGUY]

Would the json file need the diff info?

[MichaReiser]

I see this as a multip step process, similar to how the parser coverage works

• The DiffReporter has an option to emit a JSON instead of a md file
• There's a new xtask command that given two paths to such report JSON files prints a nice table with the diff (see xtask coverage compare)