Bicep Linter and Config

The Bicep linter reads a file and reports risky or untidy code before deployment. It flags unused parameters, hard-coded values, outdated API versions, and secrets that leak into outputs. A configuration file called bicepconfig.json controls how strict each check behaves.

Think of a spell checker in a word processor. The checker underlines mistakes while the author types, and the author fixes them before sending the document. The linter does the same job for infrastructure code.

Where the Linter Runs

   Editor (VS Code)  ──► underlines problems while you type
   Command line      ──► az bicep lint --file main.bicep
   Pipeline          ──► blocks the build when a rule fails

Run the Linter

The Visual Studio Code extension runs the linter automatically. The command line runs it on demand.

az bicep lint --file main.bicep

Warnings and errors print with the rule name, the file, and the line number.

Example Problems the Linter Finds

param unusedValue string          // no-unused-params
var oldUrl = 'https://management.azure.com'   // no-hardcoded-env-urls

@secure()
param adminPassword string = 'P@ssw0rd'     // secure-parameter-default

Each line triggers a rule. The first parameter never gets used, the second line hard-codes an Azure address that differs in other clouds, and the third line stores a password as a default value.

The bicepconfig.json File

Place the file in the project folder. Bicep applies the closest configuration file it finds, searching upward from the Bicep file. Each rule takes a level of off, info, warning, or error.

{
  "analyzers": {
    "core": {
      "rules": {
        "no-unused-params": { "level": "error" },
        "no-unused-vars": { "level": "error" },
        "no-hardcoded-env-urls": { "level": "warning" },
        "secure-parameter-default": { "level": "error" },
        "outputs-should-not-contain-secrets": { "level": "error" },
        "use-recent-api-versions": { "level": "warning" }
      }
    }
  }
}

Useful Rules

Rule	What It Catches
no-unused-params	Parameters that nothing reads
no-unused-vars	Variables that nothing reads
no-hardcoded-env-urls	Fixed Azure web addresses
secure-parameter-default	Default values on secure parameters
outputs-should-not-contain-secrets	Outputs that expose passwords or keys
use-recent-api-versions	Resource API versions that have aged
prefer-interpolation	Concatenation that interpolation expresses better

Suppress a Rule on One Line

A directive comment silences a rule on the line that follows when a deliberate exception exists. Add a reason so reviewers understand the choice.

#disable-next-line no-hardcoded-env-urls
var legacyUrl = 'https://management.azure.com'

Linting in Pipelines

A pipeline step that runs az bicep lint stops weak code from reaching production. Set important rules to error so the build fails, and keep style rules at warning so developers see them without blocking work.

Team Setup Tips

Commit bicepconfig.json to the repository so everyone shares identical rules. Start with a few strict rules and expand over time. A sudden wall of warnings on an old codebase discourages people, while a gradual rollout builds the habit.

Why the Linter Saves Time

Reviewers spend less energy on small details when a tool already caught them. Teams discuss design instead of unused variables. New members learn good habits from the messages, since each rule explains the issue and points to a fix.

Summary

The linter checks Bicep code for unused items, hard-coded values, old API versions, and secret leaks. The bicepconfig.json file sets each rule to off, info, warning, or error. Editors, command lines, and pipelines all run the same checks, and directive comments handle rare exceptions.