Add prettier and format everything (#1081)

* Add prettier and format everything

* add extensions

* use full defaults

* add to ci

* add pre-commit hook

* remove lefthook

Author: jderochervlk

.github/ISSUE_TEMPLATE/documentation_issue.md

@@ -1,9 +1,7 @@
 ---
 name: 🚨 Documentation issue
 about: Create an issue to help us improve the rescript-lang.org documentation website
-title: ''
-labels: ''
-assignees: ''
-
+title: ""
+labels: ""
+assignees: ""
 ---
-

.github/workflows/pull-request.yml

@@ -12,6 +12,7 @@ jobs:
       - run: npm ci
       - run: npx rescript
       - run: npm test
+      - run: npm run ci:format
 
       - name: Format check
         run: npx rescript format -check -all

.gitignore

@@ -22,7 +22,6 @@ _tempFile.cmt
 .bsb.lock
 .merlin
 lib/
-.vscode/
 
 .vercel
 

.prettierrc

@@ -0,0 +1,2 @@
+plugins:
+  - "@prettier/plugin-oxc"

.vscode/extensions.json

@@ -0,0 +1,3 @@
+{
+  "recommendations": ["esbenp.prettier-vscode", "chenglou92.rescript-vscode"]
+}

CHANGELOG.md

@@ -1,6 +1,5 @@
 # Changelog
 
-
 This changelog documents significant changes that caused a new version in the manual, or other related resources.
 
 We don't create a version fork for every minor release, and try to make docs "append only" as much as possible. Usually when we introduce a new feature we add a `since 9.0` annotation to a specific section, and be done with it.
@@ -13,8 +12,7 @@ Here are the notes on major changes we did, and how the version corresponds to s
 
 ### latest
 
-- 9.1 related
-  -
+- ## 9.1 related
 
 ### v9.0 (v8.3 - v9.0)
 
@@ -34,5 +32,3 @@ Here are the notes on major changes we did, and how the version corresponds to s
 ### v8.0.0 (v6 - v8.3)
 
 - Docs with Reason / OCaml syntax before the new syntax
-
-

README.md

@@ -1,4 +1,5 @@
 # rescript-lang.org
+
 [![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-v1.4%20adopted-ff69b4.svg)](CODE_OF_CONDUCT.md)
 
 This is the official documentation platform for the [ReScript](https://rescript-lang.org) programming language.

_blogposts/2020-08-10-bucklescript-is-rebranding.mdx

@@ -21,13 +21,15 @@ We're pleased to announce that BuckleScript is getting a brand new name: **ReScr
 ## Community Situation
 
 BuckleScript started with the idea that **JavaScript programmers deserved a great typed language with a fast and lean toolchain**. This idea took root and, over the years, we've gradually accomplished feats such as:
+
 - a state of the art compiled JavaScript output that rivals hand-written JS,
 - a fast & reliable toolchain much needed in front-end and Node development,
 - various JS interop features that spawned an ecosystem of well typed libraries,
 - a production-ready standard library,
 - [and recently](/blog/bucklescript-8-1-new-syntax), a fresh syntax made by a major contributor of Reason's old syntax.
 
 These developments have attracted many people into our community. But one bigger challenge persisted: newcomers dropped out at the sheer amount of extra incongruent tools and learning overhead from having to understand OCaml concepts, Reason concepts, and BuckleScript's concepts. Take, for example, what's required to make a React app using BuckleScript:
+
 - Knowledge of React.
 - Knowledge of JS.
 - Knowledge of BuckleScript's specific bindings to React (that we've tried hard to keep to a minimum).
@@ -43,6 +45,7 @@ The adoption barrier is real, and it's about time we finally solve it.
 ## The Rebranding
 
 Today, we'll start to truly unify the various BuckleScript-related projects under the ReScript umbrella. This includes:
+
 - The compiler, build system and the new syntax unified under a single installation.
 - Doubling down on editor tooling for ReScript usage.
 - A single documentation site (this one), which unifies all the docs and greatly trims down on redundant and stale info.

_blogposts/2020-08-28-new-rescript-logo.mdx

@@ -15,35 +15,44 @@ ReScript is the evolution and fusion of Reason and BuckleScript. As we're a desi
 
 Here it is!
 
-
-<Image withShadow={false} src="/static/blog/rescript-launch/ReScript-1.jpg" caption="Comparison between the Reason, BuckleScript and ReScript logos"/>
-
+<Image
+  withShadow={false}
+  src="/static/blog/rescript-launch/ReScript-1.jpg"
+  caption="Comparison between the Reason, BuckleScript and ReScript logos"
+/>
 
 The old Reason and BuckleScript logo had many limitations:
+
 - The icons didn't really work well on round Social Media profile images (or round shapes at all).
 - There's no guideline on how the logo works inverted, or on colored background.
 - The large red rectangle makes it difficult to balance the logo with other elements.
 - The buckle and belt were a bit too literal and did not convey much.
 
 The new logo addresses all these and more:
 
-<Image withShadow={false} src="/static/blog/rescript-launch/ReScript-2.jpg" caption="Logo comparison on social media"/>
+<Image
+  withShadow={false}
+  src="/static/blog/rescript-launch/ReScript-2.jpg"
+  caption="Logo comparison on social media"
+/>
 
 ## Creating Meaning Through Simple Shapes
 
 A minimal logo design is achieved by putting aside all distractions while focusing on legibility, meaning and small details like clear lines, interesting perspective and depth.
 
-
-<Image withShadow={false} src="/static/blog/rescript-launch/ReScript-4.jpg" caption="ReScript logo variations and usage examples"/>
-
+<Image
+  withShadow={false}
+  src="/static/blog/rescript-launch/ReScript-4.jpg"
+  caption="ReScript logo variations and usage examples"
+/>
 
 **The letter "r"**, composed of two shapes, is inspired by Albers, a german-born American Bauhaus artist and typographer. An object should be simple, beautiful, functional and accessible for everyone - a statement which applies to ReScript's principles perfectly.
 
 **I/O**: The rectangle and circle represent the input / output, recalling the digital nature of a program.
 
 **The red app-shaped background** references the vibrant, playful applications our developers are empowered to create with ReScript.
 
-**The Logotype**  ("rescript") complements the brand mark with its clean look and its embrace of technology while retaining a functional look.
+**The Logotype** ("rescript") complements the brand mark with its clean look and its embrace of technology while retaining a functional look.
 
 We'd like to position ReScript to be a community of product-first developers who care about the fit & finish of their work, while keeping an eye on the quality of their engineering. This interplay of design and engineering is a hard-to-achieve but beautifully worthwhile sweet spot that's frequently been missing in the programmer community; our vibrant logo is our renewed symbolic step toward this mission. Come along with us on our journey!
 

_blogposts/2020-09-25-release-8-3-2.mdx

@@ -74,7 +74,7 @@ To get the build output, instead of communicating through IPC, we adopted a simp
 This makes the editor integration build-system agnostic, it does not need talk to the build system directly.
 
 It also makes our build tool work with other watchers including Facebook's [watchman](https://facebook.github.io/watchman/).
-Watchman is  a more scalable watcher tool for some specific platforms and less memory hungry, however, we still need a watchman-client to get the output of triggered job.
+Watchman is a more scalable watcher tool for some specific platforms and less memory hungry, however, we still need a watchman-client to get the output of triggered job.
 We write the output to `.compiler.log` per each build, allowing clients to read compiler diagnostics when they want.
 
 ## A better algorithm for removing stale outputs
@@ -90,8 +90,8 @@ We scan `lib/bs` directory and check some dangling `cm{i,t,j,ti}` files, if it d
 the current build set, it is considered stale artifacts. If it is `cmt` file, it would trigger some hooks of `genType`, notably -cmt-rm.
 
 - Based on previous build logs
-We store previous compilation stats.  If a file is in the previous compiler output, but no longer in the output of the new build, it is considered stale and can be removed.
-it is considered stale output which can be removed.
+  We store previous compilation stats. If a file is in the previous compiler output, but no longer in the output of the new build, it is considered stale and can be removed.
+  it is considered stale output which can be removed.
 
 In general, strategy two is more reliable and efficient.
 
@@ -100,11 +100,9 @@ In general, strategy two is more reliable and efficient.
 
 However, strategy one is easier for tooling like `genType`. Not every tool has knowledge of the build system.
 
-
 Sometimes a combination of both strategies is needed.
-- When removing .cm* files, we use the first strategy.
-- When removing generated javascript, we use strategy two,
-
 
+- When removing .cm\* files, we use the first strategy.
+- When removing generated javascript, we use strategy two,
 
 Happy Hacking!