update command section

website/content/docs/commands/fix.mdx

@@ -10,6 +10,8 @@ sidebar_title: <tt>fix</tt>
 
 # `fix` Command
 
+-> **Note** This command is compatible only with legacy JSON templates.
+
 The `packer fix` command takes a template and finds backwards incompatible
 parts of it and brings it up to date so it can be used with the latest version
 of Packer. After you update to a new Packer release, you should run the fix

website/content/docs/commands/fmt.mdx

@@ -22,15 +22,15 @@ Check if configuration file(s) need to be formatted, but don't write the changes
 
 ```shell-session
 $ packer fmt -check .
-my-template.json
+my-template.pkr.hcl
 
 ```
 
 Format a configuration file, writing the changes back to the original file.
 
 ```shell-session
-$ packer fmt my-template.json
-my-template.json
+$ packer fmt my-template.pkr.hcl
+my-template.pkr.hcl
 
 ```
 

website/content/docs/commands/inspect.mdx

@@ -5,7 +5,7 @@ description: >
   components a template defines. This can help you quickly learn about a
   template
 
-  without having to dive into the JSON itself. The command will tell you things
+  without having to dive into the HCL itself. The command will tell you things
 
   like what variables a template accepts, the builders it defines, the
 
@@ -18,7 +18,7 @@ sidebar_title: <tt>inspect</tt>
 
 The `packer inspect` command takes a template and outputs the various
 components a template defines. This can help you quickly learn about a template
-without having to dive into the JSON itself. The command will tell you things
+without having to dive into the HCL itself. The command will tell you things
 like what variables a template accepts, the builders it defines, the
 provisioners it defines and the order they'll run, and more.
 
@@ -35,19 +35,29 @@ of your template by necessity.
 Given a basic template, here is an example of what the output might look like:
 
 ```shell-session
-$ packer inspect template.json
-Variables and their defaults:
+$ packer inspect template.pkr.hcl
+> input-variables:
 
-  aws_access_key =
-  aws_secret_key =
+var.aws_access_key: "<sensitive>"
+var.aws_secret_key: "<sensitive>"
 
-Builders:
+> local-variables:
 
-  amazon-ebs
-  amazon-instance
-  virtualbox-iso
+> builds:
 
-Provisioners:
+  > <unnamed build 0>:
 
-  shell
+    sources:
+
+      amazon-ebs.foo
+      amazon-instance.bar
+      virtualbox-iso.basic
+
+    provisioners:
+
+      shell
+
+    post-processors:
+
+      <no post-processor>
 ```

website/content/docs/terminology.mdx

@@ -23,39 +23,42 @@ Luckily, there are relatively few. This page documents all the terminology
 required to understand and use Packer. The terminology is in alphabetical order
 for quick referencing.
 
-- `Artifacts` are the results of a single build, and are usually a set of IDs
-  or files to represent a machine image. Every builder produces a single
-  artifact. As an example, in the case of the Amazon EC2 builder, the
-  artifact is a set of AMI IDs (one per region). For the VMware builder, the
-  artifact is a directory of files comprising the created virtual machine.
+- `Commands` are sub-commands for the `packer` program that perform some job.
+  An example command is "build", which is invoked as `packer build`. Packer
+  ships with a set of commands out of the box in order to define its
+  command-line interface.
+
+- `Templates` are JSON files which define one or more builds by configuring
+  the various components of Packer. Packer is able to read a template and use
+  that information to create multiple machine images in parallel.
+
+- `Data Sources` are components of Packer that fetch data from outside Packer
+  and make it available to use within the template.
+  Example of data sources include Amazon AMI, and Amazon Secrets Manager.
 
 - `Builds` are a single task that eventually produces an image for a single
   platform. Multiple builds run in parallel. Example usage in a sentence:
   "The Packer build produced an AMI to run our web application." Or: "Packer
   is running the builds now for VMware, AWS, and VirtualBox."
 
+- `Artifacts` are the results of a single build, and are usually a set of IDs
+  or files to represent a machine image. Every builder produces a single
+  artifact. As an example, in the case of the Amazon EC2 builder, the
+  artifact is a set of AMI IDs (one per region). For the VMware builder, the
+  artifact is a directory of files comprising the created virtual machine.
+
 - `Builders` are components of Packer that are able to create a machine image
   for a single platform. Builders read in some configuration and use that to
   run and generate a machine image. A builder is invoked as part of a build
   in order to create the actual resulting images. Example builders include
-  VirtualBox, VMware, and Amazon EC2. Builders can be created and added to
-  Packer in the form of plugins.
-
-- `Commands` are sub-commands for the `packer` program that perform some job.
-  An example command is "build", which is invoked as `packer build`. Packer
-  ships with a set of commands out of the box in order to define its
-  command-line interface.
-
-- `Post-processors` are components of Packer that take the result of a
-  builder or another post-processor and process that to create a new
-  artifact. Examples of post-processors are compress to compress artifacts,
-  upload to upload artifacts, etc.
+  VirtualBox, VMware, and Amazon EC2.
 
 - `Provisioners` are components of Packer that install and configure software
   within a running machine prior to that machine being turned into a static
   image. They perform the major work of making the image contain useful
   software. Example provisioners include shell scripts, Chef, Puppet, etc.
 
-- `Templates` are JSON files which define one or more builds by configuring
-  the various components of Packer. Packer is able to read a template and use
-  that information to create multiple machine images in parallel.
+- `Post-processors` are components of Packer that take the result of a
+  builder or another post-processor and process that to create a new
+  artifact. Examples of post-processors are compress to compress artifacts,
+  upload to upload artifacts, etc.