use json markdown syntax

website/source/docs/builders/amazon-chroot.html.md

@@ -280,7 +280,7 @@ each category, the available configuration keys are alphabetized.
 
 Here is a basic example. It is completely valid except for the access keys:
 
-```javascript
+```json
 {
   "type": "amazon-chroot",
   "access_key": "YOUR KEY HERE",
@@ -307,7 +307,7 @@ However, if you want to change or add the mount points, you may using the
 `chroot_mounts` configuration. Here is an example configuration which only
 mounts `/prod` and `/dev`:
 
-```javascript
+```json
 {
   "chroot_mounts": [
     ["proc", "proc", "/proc"],
@@ -347,7 +347,7 @@ For debian based distributions you can setup a
 file which will prevent packages installed by your provisioners from starting
 services:
 
-```javascript
+```json
 {
   "type": "shell",
   "inline": [

website/source/docs/builders/amazon-ebs.html.md

@@ -150,7 +150,7 @@ builder.
   stop the instance and will wait for you to stop it manually. You can do this
   with a [windows-shell provisioner](https://www.packer.io/docs/provisioners/windows-shell.html).
 
-    ```javascript
+    ```json
     {
       "type": "windows-shell",
       "inline": ["\"c:\\Program Files\\Amazon\\Ec2ConfigService\\ec2config.exe\" -sysprep"]
@@ -335,7 +335,7 @@ builder.
 Here is a basic example. You will need to provide access keys, and may need to
 change the AMI IDs according to what images exist at the time the template is run:
 
-```javascript
+```json
 {
   "type": "amazon-ebs",
   "access_key": "YOUR KEY HERE",
@@ -372,7 +372,7 @@ configuration of `launch_block_device_mappings` will expand the root volume
 `ami_block_device_mappings` AWS will attach additional volumes `/dev/sdb` and
 `/dev/sdc` when we boot a new instance of our AMI.
 
-```javascript
+```json
 {
   "type": "amazon-ebs",
   "access_key": "YOUR KEY HERE",
@@ -410,7 +410,7 @@ Here is an example using the optional AMI tags. This will add the tags
 provide your access keys, and may need to change the source AMI ID based on what
 images exist when this template is run:
 
-```javascript
+```json
 {
   "type": "amazon-ebs",
   "access_key": "YOUR KEY HERE",

website/source/docs/builders/amazon-ebssurrogate.html.md

@@ -143,7 +143,7 @@ builder.
     stop the instance and will wait for you to stop it manually. You can do this
     with a [windows-shell provisioner](https://www.packer.io/docs/provisioners/windows-shell.html).
 
-    ```javascript
+    ```json
     {
       "type": "windows-shell",
       "inline": ["\"c:\\Program Files\\Amazon\\Ec2ConfigService\\ec2config.exe\" -sysprep"]
@@ -324,7 +324,7 @@ builder.
 
 ## Basic Example
 
-```javascript
+```json
 {
    "type" : "amazon-surrogate",
    "secret_key" : "YOUR SECRET KEY HERE",

website/source/docs/builders/amazon.html.md

@@ -105,7 +105,7 @@ the instance's IAM profile, if it has one.
 The following policy document provides the minimal set permissions necessary for
 Packer to work:
 
-```javascript
+```json
 {
   "Version": "2012-10-17",
   "Statement": [{

website/source/docs/extending/plugins.html.md

@@ -202,7 +202,7 @@ While developing plugins, you can configure your Packer configuration to point
 directly to the compiled plugin in order to test it. For example, building the
 CustomCloud plugin, I may configure packer like so:
 
-```javascript
+```json
 {
   "builders": {
     "custom-cloud": "/an/absolute/path/to/packer-builder-custom-cloud"

website/source/docs/post-processors/artifice.html.md

@@ -128,7 +128,7 @@ proceeding artifact is passed to subsequent post-processors. If you use only one
 set of square braces the post-processors will run individually against the build
 artifact (the vmx file in this case) and it will not have the desired result.
 
-```javascript
+```json
 {
   "post-processors": [
     [       // <--- Start post-processor chain

website/source/docs/templates/builders.html.md

@@ -23,7 +23,7 @@ referenced from the documentation for that specific builder.
 
 Within a template, a section of builder definitions looks like this:
 
-```javascript
+```json
 {
   "builders": [
     // ... one or more builder definitions here

website/source/docs/templates/post-processors.html.md

@@ -25,7 +25,7 @@ post-processor.
 
 Within a template, a section of post-processor definitions looks like this:
 
-```javascript
+```json
 {
   "post-processors": [
     // ... one or more post-processor definitions here

website/source/docs/templates/provisioners.html.md

@@ -25,7 +25,7 @@ be referenced from the documentation for that specific provisioner.
 
 Within a template, a section of provisioner definitions looks like this:
 
-```javascript
+```json
 {
   "provisioners": [
     // ... one or more provisioner definitions here

website/source/docs/templates/push.html.md

@@ -22,7 +22,7 @@ services will come in the form of plugins in the future.
 
 Within a template, a push configuration section looks like this:
 
-```javascript
+```json
 {
   "push": {
     // ... push configuration here

website/source/docs/templates/user-variables.html.md

@@ -33,7 +33,7 @@ The `variables` section is a simple key/value mapping of the variable name to a
 default value. A default value can be the empty string. An example is shown
 below:
 
-```javascript
+```json
 {
   "variables": {
     "aws_access_key": "",

website/source/intro/getting-started/parallel-builds.html.md

@@ -73,7 +73,7 @@ array.
 You'll also need to modify the `variables` section of the template to include
 the access keys for DigitalOcean.
 
-```javascript
+```json
 "variables": {
   "do_api_token": "",
   // ...