Azure Bicep

The Bicep compiler processes code through several distinct stages to transform Bicep files into ARM JSON templates:

1. Parser: Converts text into an in-memory syntax tree using a lexer (tokenization) and a recursive-descent parser.
2. Binder: Associates named identifiers (symbols) in the syntax tree with their definitions by building a symbol table.
3. Semantic Analysis: Performs deep queries on the document, including:
   • Type Checking: Uses a TypeManager to verify types and a TypeAssignmentVisitor to catch invalid assignments.
   • Linters: Runs best-practice and code-style checks (configurable via Bicep configuration files).
   • Emit Limitation Calculation: Identifies patterns that would result in invalid ARM templates or violate service-side limitations.
4. Emitter: Collects information from all previous stages to generate the final ARM JSON Template. Emitting is blocked if any diagnostic errors were raised in earlier stages.

The Bicep repository is organized into several key functional areas:

• Bicep.Core: The central library containing the compiler pipeline logic. It is used by most other projects in the repository.
• Bicep.Cli: The command-line interface tool. It provides commands like bicep build and bicep decompile. Official releases are distributed as self-contained, single-file applications.
• Bicep.LangServer: An implementation of the Language Server Protocol (LSP). It provides IDE features like autocomplete and 'goto definition' by handling notifications and requests from clients like VS Code.
• VSCode Extension: Located in vscode-bicep, this extension uses a language client to communicate with the Bicep language server via LSP over JSON-RPC. It also includes a React-based visualizer that renders resource dependency graphs in a VS Code webview.
• Decompiler: A peripheral component that uses a heuristic-based approach to generate Bicep representations from existing ARM JSON templates.

For services that implement the actual logic (e.g., FileSystemService), use integration-style tests. To ensure isolation and prevent side effects on the host machine, create a unique temporary directory in [TestInitialize] and delete it recursively in [TestCleanup].

[TestClass]
public class FileSystemServiceTests
{
    private string _testDirectory = null!;
    private FileSystemService _service = null!;

    [TestInitialize]
    public void Setup()
    {
        _testDirectory = Path.Combine(Path.GetTempPath(), $"test_{Guid.NewGuid()}");
        Directory.CreateDirectory(_testDirectory);
        _service = new FileSystemService();
    }

    [TestCleanup]
    public void Cleanup()
    {
        if (Directory.Exists(_testDirectory))
        {
            Directory.Delete(_testDirectory, recursive: true);
        }
    }

    [TestMethod]
    public async Task WriteFileAsync_CreatesFileWithContent()
    {
        // Arrange
        var filePath = Path.Combine(_testDirectory, "test.txt");
        var content = "Hello, World!";

        // Act
        await _service.WriteFileAsync(filePath, content, CancellationToken.None);

        // Assert
        File.Exists(filePath).Should().BeTrue();
        (await File.ReadAllTextAsync(filePath)).Should().Be(content);
    }
}