Use proper syntax highlighting for code blocks (#615)

* Better syntax highlighting

* Better syntax highlighting

CONTRIBUTING.md

@@ -109,7 +109,7 @@ A good test plan has the exact commands you ran and their output, provides scree
 
 When adding a new breaking change, follow this template in your pull request:
 
-```
+```md
 ### New breaking change here
 
 * **Who does this affect**:
@@ -122,7 +122,7 @@ When adding a new breaking change, follow this template in your pull request:
 
 Copy and paste this to the top of your new file(s):
 
-```JS
+```js
 /**
  * Copyright (c) 2017-present, Facebook, Inc.
  *

admin/extending-remarkable.md

@@ -4,8 +4,8 @@ Docusaurus uses [Remarkable](https://github.com/jonschlinkert/remarkable) to con
 
 Users of GitHub Pages have come to expect certain features provided by GitHub Flavored Markdown. One such example would be heading anchors, where every sub-header has an associated anchor that matches the heading text. This makes it possible to link to a specific section in a document by passing a fragment that matches the heading. For example, to link to this very section, you may create a link like so:
 
-```
-    [Link to this section](#why-extend-remarkable)
+```md
+[Link to this section](#why-extend-remarkable)
 ```
 
 ## A Brief Overview of How A Markdown Parser/Renderer Works
@@ -26,7 +26,7 @@ Inline tokens are simple tokens that have text as a child. They are leaf nodes,
 
 A block token is a bit more complex. It may wrap one or more tokens, and can span more than one line of text. An example of this is the heading token:
 
-```
+```md
 ### Hi there
 ```
 
@@ -52,7 +52,7 @@ Now that you have a better idea of how parsing/rendering works, we can proceed t
 
 The default heading renderers may look like this (you can refer to the Remarkable source code here):
 
-```
+```js
 md.renderer.rules.heading_open = function(tokens, idx /*, options, env */) {
   return '<h' + tokens[idx].hLevel + '>';
 };
@@ -64,13 +64,13 @@ md.renderer.rules.heading_close = function(tokens, idx /*, options, env */) {
 
 That's pretty straightforward: whenever these tokens are found, we render a `<hN>` or `</hN>` HTML tag, where N is the `hLevel` for this heading. That would result in `<h3>Hi there</h3>` being output. But what we want is something closer to this:
 
-```
+```html
 <h3><a class="anchor" id="hi-there"></a>Hi there <a class="hash-link" href="#hi-there">#</a></h3>
 ```
 
 In that case, we need to override our heading rules like so:
 
-```
+```js
 md.renderer.rules.heading_open = function(tokens, idx /*, options, env */) {
   return '<h' + tokens[idx].hLevel + '>' + '<a class="anchor" id="' + toSlug(tokens[idx+1].content) + '"></a>';
 };
@@ -86,7 +86,7 @@ Note that we are referring to `tokens[idx+1]` and `tokens[idx-1]` at various poi
 
 We now need to tell Remarkable to use our extension. We can wrap our rules in a function called `anchors`:
 
-```
+```js
 function anchors(md) {
   md.renderer.rules.heading_open = function(tokens, idx /*, options, env */) {
     return '<h' + tokens[idx].hLevel + '>' + '<a class="anchor" id="' + toSlug(tokens[idx+1].content) + '"></a>';
@@ -100,10 +100,10 @@ function anchors(md) {
 
 We can now tell Remarkable to load this function as a plugin (`md` is our instance of Remarkable):
 
-```
+```js
 this.md.use(anchors);
 ```
 
 ### Future Work
 
-A more advanced extension might add additional parser rules. These rules may add support for new markdown syntax not covered by Remarkable. Say, for example, a custom syntax to embed video when a tag like `@video` is found can be supported by generating a new type of token, that is later used by the renderer to output the necessary `<embed>` HTML tags. This is left as an exercise to the reader for now.
+A more advanced extension might add additional parser rules. These rules may add support for new markdown syntax not covered by Remarkable. Say, for example, a custom syntax to embed video when a tag like `@video` is found can be supported by generating a new type of token, that is later used by the renderer to output the necessary `<embed>` HTML tags. This is left as an exercise to the reader for now.

admin/local-third-party-project-testing.md

@@ -10,15 +10,15 @@ There are two reasonable ways to use a local version of the Docusaurus npm packa
 
 ### Install the package from the Docusaurus repo
 
-```
+```bash
 cd /path/to/testing_project
 mkdir website # if this does not exist already
 cd website
 ```
 
 If you do not have a `package.json` file in the `website` directory, create one with the following content:
 
-```
+```json
 {
   "scripts": {
     "start": "docusaurus-start",
@@ -31,7 +31,7 @@ If you do not have a `package.json` file in the `website` directory, create one
 
 Then:
 
-```
+```sh
 # Path to your Docusaurus clone
 npm install ../../path/to/docusaurus/
 ```
@@ -46,7 +46,7 @@ Error: Couldn't find preset "react" relative to directory
 
 So, you should install these packages locally. **Base the versions on the versions defined in the Docusaurus `package.json`**. e.g.,
 
-```
+```bash
 # Still in the website directory of the testing project
 npm install babel-plugin-transform-class-properties@^6.24.1
 npm install babel-plugin-transform-object-rest-spread@^6.26.0
@@ -57,7 +57,7 @@ npm install babel-preset-react@^6.24.0
 
 ### Test
 
-```
+```bash
 ./node_modules/.bin/docusaurus-examples # or whatever you want to test, if anything
 ./node_modules/.bin/docusaurus-start
 ```
@@ -68,7 +68,7 @@ Verdaccio is a good local npm server that you can use to test your packages.
 
 ### Install verdaccio
 
-```
+```bash
 npm install --global verdaccio
 ```
 
@@ -78,13 +78,13 @@ When you are ready to test the code that could make up the next version of your
 
 Run verdaccio in a **separate terminal window**:
 
-```
+```bash
 verdaccio
 ```
 
 In another terminal window, get ready to publish your local npm package:
 
-```
+```bash
 # Your clone of Docusaurus
 cd /path/to/docusaurus/
 
@@ -101,15 +101,15 @@ You can navigate to localhost:4873 and you can see that your package was publish
 
 Now install the package in the repo you want to test Docusaurus on.
 
-```
+```bash
 cd /path/to/testing_project/
 mkdir website # if this does not exist already
 cd website
 ```
 
 If you do not have a `package.json` file in the `website` directory, create one with the following content:
 
-```
+```json
 {
   "scripts": {
     "start": "docusaurus-start",
@@ -122,7 +122,7 @@ If you do not have a `package.json` file in the `website` directory, create one
 
 Then:
 
-```
+```bash
 npm install docusaurus --registry http://localhost:4873 # this may be slower than the normal npm registry
 npm run examples # or whatever you want to test, if anything
 npm run start

admin/publish.md

@@ -18,13 +18,16 @@ If you are not currently logged into npm locally:
 
 The version number should generally increase by some factor than the current one. You can check current version by looking in `package.json`.
 
-```
-"name": "docusaurus",
-"version": "1.0.0-alpha.41",
-"repository": {
-  "type": "git",
-  "url": "https://github.com/facebook/Docusaurus.git"
-},
+```json
+{
+  "name": "docusaurus",
+  "version": "1.0.0-alpha.41",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/facebook/Docusaurus.git"
+  }
+  ...
+}
 ```
 
 For the above example, you may want to bump the version to `1.0.0-alpha.42` or `1.0.0-beta.1` or `1.0.1`.

admin/testing-changes-on-Docusaurus-itself.md

@@ -6,7 +6,7 @@ If you are developing the Docusaurus core and you want a quick way to test your
 
 It is straightforward to test your Docusaurus changes with Docusaurus.
 
-```
+```bash
 cd /path/to/docusaurus-repo
 npm install
 cd website
@@ -21,7 +21,7 @@ npm run start
 
 Use the following code in VSCode to enable breakpoints. Please ensure you have a later version of node for non-legacy debugging.
 
-```
+```json
 {
   "version": "0.2.0",
   "configurations": [

docs/api-commands.md

@@ -13,13 +13,13 @@ Docusaurus provides a set of scripts to help you generate, serve, and deploy you
 
 The scripts can be run using either Yarn or npm. If you've already gone through our Getting Started guide, you may already be familiar with the `start` command. It's the command that tells Docusaurus to run the `docusaurus-start` script which generates the site and starts up a server, and it's usually invoked like so:
 
-```
+```bash
 yarn run start
 ```
 
 The same script can be invoked using npm:
 
-```
+```bash
 npm run start
 ```
 
@@ -29,13 +29,13 @@ To run a particular script, just replace the `start` command in the examples abo
 
 Some commands support optional arguments. For example, to start a server on port 8080, you can specify the `--port` argument when running `start`:
 
-```
+```bash
 yarn run start --port 8080
 ```
 
 If you run Docusaurus using npm, you can still use the command line arguments by inserting a `--` between `npm run <command>` and the command arguments:
 
-```
+```bash
 npm run start -- --port 8080
 ```
 
@@ -54,6 +54,7 @@ Docusaurus provides some default mappings to allow you to run commands following
 ## Reference
 
 ### `docusaurus-build`
+
 Alias: `build`.
 
 Generates the static website, applying translations if necessary. Useful for building the website prior to deployment.
@@ -63,13 +64,15 @@ See also [`docusaurus-start`](api-commands.md#docusaurus-start-port-number).
 ---
 
 ### `docusaurus-examples [feature]`
+
 Alias: `examples`
 
 When no feature is specified, sets up a minimally configured example website in your project. This command is covered in depth in the [Site Preparation guide](getting-started-preparation.md). Specify a feature `translations` or `versions` to generate the extra example files for that feature.
 
 ---
 
 ### `docusaurus-publish`
+
 Alias: `publish-gh-pages`
 
 [Builds](api-commands.md#docusaurus-build), then deploys the static website to GitHub Pages. This command is meant to be run during the deployment step in Circle CI, and therefore expects a few environment variables to be defined:
@@ -100,6 +103,7 @@ You can learn more about configuring automatic deployments with CircleCI in the
 ---
 
 ### `docusaurus-rename-version <currentVersion> <newVersion>`
+
 Alias: `rename-version`
 
 Renames an existing version of the docs to a new version name.
@@ -109,13 +113,15 @@ See the [Versioning guide](guides-versioning.md#renaming-existing-versions) to l
 ---
 
 ### `docusaurus-start [--port <number>]`
+
 Alias: `start`.
 
 This script will build the static website, apply translations if necessary, and then start a local server. The website will be served from port 3000 by default.
 
 ---
 
 ### `docusaurus-version <version>`
+
 Alias: `version`
 
 Generates a new version of the docs. This will result in a new copy of your site being generated and stored in its own versioned folder. Useful for capturing snapshots of API docs that map to specific versions of your software. Accepts any string as a version number.
@@ -125,6 +131,7 @@ See the [Versioning guide](guides-versioning.md) to learn more.
 ---
 
 ### `docusaurus-write-translations`
+
 Alias: `write-translations`
 
 Writes the English for any strings that need to be translated into an `website/i18n/en.json` file. The script will go through every file in `website/pages/en` and through the `siteConfig.js` file and other config files to fetch English strings that will then be translated on Crowdin. See the [Translation guide](guides-translation.md) to learn more.