Prettier!

Author: iHiD

.gitignore

@@ -0,0 +1 @@
+node_modules/

.prettierrc

@@ -0,0 +1,18 @@
+{
+  "arrowParens": "always",
+  "bracketSpacing": true,
+  "endOfLine": "auto",
+  "htmlWhitespaceSensitivity": "css",
+  "insertPragma": false,
+  "jsxBracketSameLine": false,
+  "jsxSingleQuote": false,
+  "printWidth": 80,
+  "proseWrap": "preserve",
+  "quoteProps": "as-needed",
+  "semi": false,
+  "singleQuote": true,
+  "tabWidth": 2,
+  "trailingComma": "es5",
+  "useTabs": false,
+  "vueIndentScriptAndStyle": false,
+}

README.md

@@ -7,6 +7,7 @@ These are the official docs for Exercism. We welcome all and any contributions.
 ## How this repo is organised
 
 There are three top-level repositories:
+
 - **anatomy:** How Exercism fits together with technical specs for maintainers.
 - **product:** The product philosophy and decisions behind Exercism.
 - **user-facing:** User facing docs for FAQs, help, etc

TODO.md

@@ -1,3 +1,3 @@
-# TODO 
+# TODO
 
 These are things that should be done before this repo becomes public:

anatomy/README.md

@@ -3,4 +3,3 @@
 The documents in this section explore the different areas of Exercism, how they are built, and the technical specifications for each area.
 
 These documents are written for maintainers and contributors to Exercism, rather than end-users, and so may presume more innate knowledge of Exercism.
-

anatomy/test-runners/README.md

@@ -3,10 +3,11 @@
 A Test Runner is a piece of software that runs a an exercise's tests against a student's code.
 
 Test runners give us two advantages
-1. They enable in-browser coding, where a student can iterate on a solution seeing whether the tests pass or fail. 
+
+1. They enable in-browser coding, where a student can iterate on a solution seeing whether the tests pass or fail.
 2. They allow us to provide information to mentors on whether a student's code "works" or not.
 
-Each language has it's own test runner, written in that language. 
+Each language has it's own test runner, written in that language.
 The website acts as the orchestrator between the test runners and student's submissions.
 
 Each test runner lives in the Exercism GitHub organsation in a repository named `$LANG-test-runner` (e.g. `ruby-test-runner`).
@@ -16,9 +17,7 @@ If you would like to get involved in helping with an existing Test Runner, pleas
 If you would like to create a Test Runner for a language that currently does not have one, please follow the [creating a Test Runner](creating-from-scratch.md) instructions.
 
 This directory contains the following information:
+
 - **`creating-from-scratch.md:`** Information on creating a Test Runner from scratch.
 - **`interface.md:`** The Test Runner interface.
 - **`docker.md:`** How to build a Docker image with Docker for local testing and deployment.
-
-
-

anatomy/test-runners/docker.md

@@ -10,21 +10,21 @@ The Dockerfile should create the minimal image needed for the Test Runner to run
 
 It should produce an image with as a small a size as possible.
 The minimal-sized image is often based on Alpine Linux.
-Applying the official [Dockerfile best practices](https://docs.docker.com/develop/develop-images/Dockerfile_best-practices/) can help to create a minimal image. 
+Applying the official [Dockerfile best practices](https://docs.docker.com/develop/develop-images/Dockerfile_best-practices/) can help to create a minimal image.
 
 ## Executing the Docker container
 
 When we run the Docker container we execute a `run.sh` script.
 To ensure this works properly the following rules must be following:
 
 - The working directory should be `/opt/test-runner`.
-- There should be a `/opt/test-runner/bin/run.sh` script that can be called with 3 parameters: 
+- There should be a `/opt/test-runner/bin/run.sh` script that can be called with 3 parameters:
   the `exercise slug`, the path to the `solution folder`, and the path to the `output folder`.
   For more information see [The Interface](./interface.md).
 
 ## Local development
 
-To allow for local development we have produced an exectuable called [tooling-webserver](https://github.com/exercism/tooling-webserver/blob/master/README.md#installation-docker). 
+To allow for local development we have produced an exectuable called [tooling-webserver](https://github.com/exercism/tooling-webserver/blob/master/README.md#installation-docker).
 Please follow its installation instructions.
 
 ## Creating/editing a Dockerfile

anatomy/test-runners/interface.md

@@ -27,7 +27,7 @@ The `results.json` file should be structured as followed:
       "status": "fail",
       "message": "Expected 42 but got 123123",
       "output": "Debugging information output by the user",
-      "cmd": "assert_equal 42, answerToTheUltimateQuestion()",
+      "cmd": "assert_equal 42, answerToTheUltimateQuestion()"
     }
   ]
 }
@@ -40,6 +40,7 @@ The `results.json` file should be structured as followed:
 > key: `status`
 
 The following overall statuses are valid:
+
 - `pass`: All tests passed
 - `fail`: At least one test failed
 - `error`: To be used when the tests did not run correctly (e.g. a compile error, a syntax error)
@@ -65,18 +66,20 @@ This is the name of the test in a human-readable format.
 > key: `cmd`
 
 This is the body of the command that is being tests. It should have any `skip` annotations removed. For example, the following Ruby test:
+
 ```ruby
-  def test_duplicate_items_uniqs_list
-    skip
-    cart = ShoppingCart.new
-    cart.add(:STARIC)
-    cart.add(:MEDNEW)
-    cart.add(:MEDNEW)
-    assert_equal 'Newspaper, Rice', cart.items_list
-  end
+def test_duplicate_items_uniqs_list
+  skip
+  cart = ShoppingCart.new
+  cart.add(:STARIC)
+  cart.add(:MEDNEW)
+  cart.add(:MEDNEW)
+  assert_equal 'Newspaper, Rice', cart.items_list
+end
 ```
 
 ... should return a cmd value of:
+
 ```ruby
 "cart = ShoppingCart.new
 cart.add(:STARIC)
@@ -92,6 +95,7 @@ assert_equal 'Newspaper, Rice', cart.items_list"
 > key: `status`
 
 The following per-test statuses are valid:
+
 - `pass`: The test passed
 - `fail`: The test failed
 - `error`: The test errored
@@ -138,7 +142,8 @@ Test Code:
 
 ### How to add metadata for your language's test suite
 
-All roads lead to Rome and there is no prescribed pattern to arrive at this. There are several approaches taken so far:
+All roads lead to Rome and there is no prescribed pattern to arrive at this.
+There are several approaches taken so far:
 
 - Auxillary JSON files compiled manually, merged with test results during the test run-time.
 - Automated static analysis of the test suite, merged with test results during the test run-time.

package.json

@@ -0,0 +1,12 @@
+{
+  "devDependencies": {
+    "husky": "^4.2.5",
+    "pretty-quick": "^2.0.1",
+    "prettier": "^2.0.5"
+  },
+  "husky": {
+    "hooks": {
+      "pre-commit": "pretty-quick --staged"
+    }
+  }
+}

product/README.md

@@ -1,16 +1,19 @@
 # Product Docs
 
-These documents outline the product decisions and thinking behind Exercism. 
+These documents outline the product decisions and thinking behind Exercism.
 They aim to present a picture of why things on Exercism work the way they do.
 
 ## Exercism Concepts
+
 - [Reputation](./reputation.md)
 - [Credits](./credits.md)
 
 ## Language Tracks
+
 - [General info](./tracks.md)
 
 ### Exercises
+
 - [Practice Exercises](./practice-exercises.md)
 - [Concept Exercises](./concept-exercises.md)
 

product/concept-exercises.md

@@ -9,18 +9,21 @@ Concept Exercises have the following characteristics:
 - Stubs/boilerplate are used to avoid the student having to learn/write unnecessary code on exercises.
 
 ## Concepts
-Exercises are unlocked based on concepts taught and learnt. 
-Each Concept Exercise must teach one or more concepts. 
+
+Exercises are unlocked based on concepts taught and learnt.
+Each Concept Exercise must teach one or more concepts.
 It may also have prerequisites on Concepts, which means it will not be unlocked until Concept Exercises teaching those prerequisite concepts have been completed.
 
 ## Difficulty
-Concept Exercises should not become inherently more difficult as the track progresses. 
-A seasoned developer in Language X should be able to work through all the Concept Exercises on that track spending no more than 5-10 minutes solving each one. 
-As each exercise should be focussed on getting someone to use a concept for the first time, and because the seasoned developer already understands that concept in Language X, the exercise should feel relatively trivial for them. 
+
+Concept Exercises should not become inherently more difficult as the track progresses.
+A seasoned developer in Language X should be able to work through all the Concept Exercises on that track spending no more than 5-10 minutes solving each one.
+As each exercise should be focussed on getting someone to use a concept for the first time, and because the seasoned developer already understands that concept in Language X, the exercise should feel relatively trivial for them.
 Later exercises may feel more difficult to a developer unfamiliar with Language X, but only because the later exercise is teaching a concept which in itself is more complicated (for example, most people would agree Recursion is a more complex topic to learn for the first time, than a Loop is to remap from one language to another).
 
 ## Feedback
-Concept Exercises are not mentored. 
-When a student submits a submission that gets the tests passing for a Concept Exercise, we check for an Analyzer or Representer to give feedback. 
-If none is found, then the solution is approved. 
+
+Concept Exercises are not mentored.
+When a student submits a submission that gets the tests passing for a Concept Exercise, we check for an Analyzer or Representer to give feedback.
+If none is found, then the solution is approved.
 This shifts the burden of teaching to the exercise, which must provide a clear pathway to learning the concept that is being taught.

product/credits.md

@@ -17,7 +17,7 @@ A user receives a credit "present" each year upon their Exercism birthday.
 ### Mentoring
 
 Every time someone requests mentoring, they add a bounty to their request. The mentor who successfully mentors that solution receives that bounty.
- 
+
 In general, a user's [mentoring reputation](../reputation.md) determines the max bounty they can recieve. The more someone mentors (successfully), the better bounties they have access to and the more credits they can acquire.
 
 ## Spending Credits

product/experience.md

@@ -15,6 +15,7 @@ There are various ways of acquiring experience.
 Experience is acquired by successfully completing Concept and Practice Exercises.
 
 All exercises award points, but different exercises may award different amounts of points, depending on:
+
 - Whether the exercise is Concept or Practice
 - The difficulty of the exercise
 - Whether the same exercise has been completed in an alternative language (ie, you get more points the first time you complete `Bob` than the 5th time)
@@ -25,6 +26,7 @@ An algorithm considering these factors is yet to be decided.
 ### 2. Track milestones
 
 At certain points during the track, extra experience will be awarded:
+
 - Completing a Concept exercise in a track
 - Completing 10 Concept exercises in a track
 - Completing a Practice exercise in a track
@@ -41,6 +43,7 @@ Much like any modern roleplaying game, experience points are accrued and represe
 ### Level Tags
 
 Levels are also grouped into labels. For example:
+
 - 1 - 9 : Newbie
 - 10 - 19 : Explorer
 - 20 - 39 : Adventurer

product/representers.md

@@ -6,18 +6,18 @@ An example helps to explain representers best. Let's presume two students submit
 
 ```ruby
 # Student 1's submission
-def self.hello(name="World")
+def self.hello(name = 'World')
   "Hello, #{name}!"
 end
 ```
 
 ```ruby
 # Student 2's submission
-def self.hello(nom="World")
-%Q{Hello, #{nom}!}
+def self.hello(nom = 'World')
+  "Hello, #{nom}!"
 end
 ```
 
-Although the code to these solutions is different (different indentation, variable names, and string syntax), they are essentially the same. So by creating a normalised representation of them, we can *treat* them as the same for the purposes of providing feedback. This dramatically reduces the amount of duplicate mentoring that needs to happen.
+Although the code to these solutions is different (different indentation, variable names, and string syntax), they are essentially the same. So by creating a normalised representation of them, we can _treat_ them as the same for the purposes of providing feedback. This dramatically reduces the amount of duplicate mentoring that needs to happen.
 
 Each track maintains it's own representer, specific to that language. There is no standarised output - we only require a track to be internally consistent.

product/reputation.md

@@ -1,6 +1,6 @@
 # Reputation
 
-Reputation is the system that allows people to acquire "trust" within the Exericsm ecosystem. 
+Reputation is the system that allows people to acquire "trust" within the Exericsm ecosystem.
 
 Reputation is a measure of how much an individual has contributed to Exercism, both through contribution to the platform (e.g. through creation of software, exercises and docs) and contribution to the community (e.g. mentoring).
 

product/tracks.md

@@ -4,6 +4,6 @@ Tracks are Exercism's language "courses".
 
 Each track is maintained by a seperate (although sometimes overlapping) group of volunteers.
 
-Tracks are made up of [Concept Exercises](./concept-exercises.md) and [Practice Exercise](./practice-exercises.md). 
+Tracks are made up of [Concept Exercises](./concept-exercises.md) and [Practice Exercise](./practice-exercises.md).
 
-They have language-specific tooling, such as [Test Runners](./test-runners.md), [Representers](./representers.md), and [Analyzers](./analyzers.md). 
+They have language-specific tooling, such as [Test Runners](./test-runners.md), [Representers](./representers.md), and [Analyzers](./analyzers.md).