YAML Anchors and Aliases (No JSON Equivalent)

YAML anchors and aliases are a powerful feature for avoiding repetition in configuration files. They have no direct equivalent in JSON -- when converting to JSON, anchors are expanded (dereferenced) into their full values.

YAML with anchors and aliases:

defaults: &default_settings
  timeout: 30
  retries: 3
  log_level: info

development:
  <<: *default_settings
  log_level: debug
  database: dev_db

staging:
  <<: *default_settings
  database: staging_db

production:
  <<: *default_settings
  retries: 5
  database: prod_db

Converted to JSON (anchors fully expanded):

{
  "defaults": {
    "timeout": 30,
    "retries": 3,
    "log_level": "info"
  },
  "development": {
    "timeout": 30,
    "retries": 3,
    "log_level": "debug",
    "database": "dev_db"
  },
  "staging": {
    "timeout": 30,
    "retries": 3,
    "log_level": "info",
    "database": "staging_db"
  },
  "production": {
    "timeout": 30,
    "retries": 5,
    "log_level": "info",
    "database": "prod_db"
  }
}

How it works:

1. &anchor_name defines an anchor (a reusable block of data).
2. *anchor_name references the anchor (an alias that inserts the data).
3. <<: is the merge key -- it merges the referenced mapping into the current one.
4. Override values placed after the merge key take precedence. In the example, development overrides log_level from info to debug.

Anchors also work with sequences:

shared_ports: &ports
  - 80
  - 443

service_a:
  ports: *ports
service_b:
  ports: *ports

Key limitations:

• Anchors are document-scoped; they cannot reference values in other YAML files.
• JSON-to-YAML conversion cannot recreate anchors since it doesn't know which values were originally shared.
• Some YAML parsers limit anchor nesting depth to prevent billion-laughs denial-of-service attacks.

Anchors are especially useful in CI/CD configurations where multiple environments share most of their settings.