jsfmt.spec.js.snap 4.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162
  1. // Jest Snapshot v1, https://goo.gl/fbAQLP
  2. exports[`0-indent.js 1`] = `
  3. md\`
  4. This line shouldn't be indented at all in the resulting output.
  5. \`
  6. if (true) {
  7. md\`
  8. text1
  9. - 123
  10. - 456
  11. text2
  12. - 123
  13. - 456
  14. text3
  15. - 123
  16. - 456
  17. \`;
  18. }
  19. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  20. md\`
  21. This line shouldn't be indented at all in the resulting output.
  22. \`;
  23. if (true) {
  24. md\`
  25. text1
  26. - 123
  27. - 456
  28. text2
  29. - 123
  30. - 456
  31. text3
  32. - 123
  33. - 456
  34. \`;
  35. }
  36. `;
  37. exports[`codeblock.js 1`] = `
  38. md\`
  39. \\\`\\\`\\\`js
  40. markdown\\\`
  41. \\\\\\\`\\\\\\\`\\\\\\\`js
  42. console.log('hi');
  43. \\\\\\\`\\\\\\\`\\\\\\\`
  44. \\\`
  45. \\\`\\\`\\\`
  46. \`;
  47. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  48. md\`
  49. ~~~js
  50. markdown\\\`
  51. ~~~js
  52. console.log("hi");
  53. ~~~
  54. \\\`;
  55. ~~~
  56. \`;
  57. `;
  58. exports[`escape.js 1`] = `
  59. markdown\`
  60. const cssString = css\\\`
  61. background-color: \\$\\{color('base')\\}
  62. \\\`;
  63. \`
  64. markdown\`
  65. - \\\`
  66. - \\\\\\\`
  67. - \\\\\\\\
  68. - \\$
  69. - \\u1234
  70. \`
  71. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  72. markdown\`
  73. const cssString = css\\\`background-color: \\$\\{color('base')\\}\\\`;
  74. \`;
  75. markdown\`
  76. - \\\`
  77. - \\\\\\\`
  78. - \\\\\\\\
  79. - \\$
  80. - \\u1234
  81. \`;
  82. `;
  83. exports[`markdown.js 1`] = `
  84. export default function ReadMe() {
  85. return md\`
  86. ## Why Prettier?
  87. ### Building and enforcing a style guide
  88. By far the biggest reason for adopting Prettier is to stop all the on-going debates over styles. It is generally accepted that having a common style guide is valuable for a project and team but getting there is a very painful and unrewarding process. People get very emotional around particular ways of writing code and nobody likes spending time writing and receiving nits.
  89. - “We want to free mental threads and end discussions around style. While sometimes fruitful, these discussions are for the most part wasteful.”
  90. - “Literally had an engineer go through a huge effort of cleaning up all of our code because we were debating ternary style for the longest time and were inconsistent about it. It was dumb, but it was a weird on-going "great debate" that wasted lots of little back and forth bits. It's far easier for us all to agree now: just run Prettier, and go with that style.”
  91. - “Getting tired telling people how to style their product code.”
  92. - “Our top reason was to stop wasting our time debating style nits.”
  93. - “Having a githook set up has reduced the amount of style issues in PRs that result in broken builds due to ESLint rules or things I have to nit-pick or clean up later.”
  94. - “I don't want anybody to nitpick any other person ever again.”
  95. - “It reminds me of how Steve Jobs used to wear the same clothes every day because he has a million decisions to make and he didn't want to be bothered to make trivial ones like picking out clothes. I think Prettier is like that.”
  96. \`;
  97. }
  98. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  99. export default function ReadMe() {
  100. return md\`
  101. ## Why Prettier?
  102. ### Building and enforcing a style guide
  103. By far the biggest reason for adopting Prettier is to stop all the on-going
  104. debates over styles. It is generally accepted that having a common style
  105. guide is valuable for a project and team but getting there is a very painful
  106. and unrewarding process. People get very emotional around particular ways of
  107. writing code and nobody likes spending time writing and receiving nits.
  108. - “We want to free mental threads and end discussions around style. While
  109. sometimes fruitful, these discussions are for the most part wasteful.”
  110. - “Literally had an engineer go through a huge effort of cleaning up all of
  111. our code because we were debating ternary style for the longest time and
  112. were inconsistent about it. It was dumb, but it was a weird on-going
  113. "great debate" that wasted lots of little back and forth bits. It's far
  114. easier for us all to agree now: just run Prettier, and go with that
  115. style.”
  116. - “Getting tired telling people how to style their product code.”
  117. - “Our top reason was to stop wasting our time debating style nits.”
  118. - “Having a githook set up has reduced the amount of style issues in PRs
  119. that result in broken builds due to ESLint rules or things I have to
  120. nit-pick or clean up later.”
  121. - “I don't want anybody to nitpick any other person ever again.”
  122. - “It reminds me of how Steve Jobs used to wear the same clothes every day
  123. because he has a million decisions to make and he didn't want to be
  124. bothered to make trivial ones like picking out clothes. I think Prettier
  125. is like that.”
  126. \`;
  127. }
  128. `;
  129. exports[`single-line.js 1`] = `
  130. markdown\`# hello\`
  131. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  132. markdown\`
  133. # hello
  134. \`;
  135. `;