Skip to main content
Version: 7.1.0

Legacy Policy Configuration

Deprecated

Everything on this page is kept for backward compatibility but is deprecated and will be removed in a future major version. Prefer the modern configuration documented in Policies.

Legacy rules option in rules configuration​

The rules option in rules configuration (the array of per-entry dependency declarations) has been renamed to policies. rules is kept as a deprecated alias — it keeps working exactly as before.

Deprecated

Using rules prints a one-time deprecation warning (suppressible by setting boundaries/legacy-warnings to false) and it will be removed in a future major version. When both policies and rules are set, policies takes precedence.

"boundaries/dependencies": [2, {
default: "disallow",
  rules: [
  policies: [
  { from: { element: { type: "component" } }, allow: { element: { type: "helper" } } }
]
}]

For TypeScript users, the following exports are kept as @deprecated aliases: DependenciesRule (→ DependenciesPolicy), EntryPointRule (→ EntryPointPolicy), ExternalRule (→ ExternalPolicy), RulePolicy (→ RuleEffect), RULE_POLICIES_MAP (→ RULE_EFFECTS_MAP), and isRulePolicy (→ isRuleEffect).

See the v6 to v7 migration guide for more details.

Deprecated Policy Properties​

importKind (deprecated)​

Type: <string> or <array of strings> or <micromatch pattern>

Available with: TypeScript

Optional

Deprecated in v6. Use the dependency.kind metadata selector instead; when both are defined, dependency.kind takes precedence.

Specifies whether a rule applies based on how the dependency is imported.

Possible values:

  • "value" - Importing as a value
  • "type" - Importing as a type
  • "typeof" - Importing with typeof
// Components can import helpers as values
{
  from: { element: { type: "component" } },
  allow: {
    to: { element: { type: "helper" } },
    dependency: { kind: "value" }
  },
  importKind: "value"
}


// Components cannot import helper types
{
  from: { element: { type: "component" } },
  disallow: {
    to: { element: { type: "helper" } },
    dependency: { kind: "type" }
  }
  importKind: "type"
}


// Modules can import helpers as values or types
{
  from: { element: { type: "module" } },
  allow: {
    to: { element: { type: "helper" } },
    dependency: { kind: ["value", "type"] }
  }
  importKind: ["value", "type"]
}
.
// Modules can import components as any import kind
{
  from: { element: { type: "module" } },
  allow: {
    to: { element: { type: "component" } },
    dependency: { kind: "*" }
  },
  importKind: "*"
}
warning

When both policy-level importKind and dependency-level kind are defined, dependency-level kind takes precedence.

target (deprecated)​

The target property is a deprecated alias for to. It still works, but use to for clarity.

{
from: { element: { type: "component" } },
disallow: {
   target: { element: { type: "helper" } }
   to: { element: { type: "helper" } }
}
}
warning

When both target and to are defined, to takes precedence.

Legacy rule template variable​

The custom message template data exposed under rule ({{rule.index}}, {{rule.selector}}) has been renamed to policy ({{policy.index}}, {{policy.selector}}). rule is kept as a deprecated alias with the exact same shape and value.

Deprecated

{{rule.*}} is kept for backward compatibility but is deprecated and will be removed in a future major version. Use {{policy.*}} instead.

{
  "message": "Denied by policy at index {{rule.index}}"
  "message": "Denied by policy at index {{policy.index}}"
}

TypeScript users importing CustomMessageTemplateRuleContext should switch to CustomMessageTemplatePolicyContext (the old name is kept as a @deprecated alias).

See the v6 to v7 migration guide for more details.

Legacy flat message aliases​

For backward compatibility, each side also exposes V6 flat fields at the from/to root in custom message templates. These keep working but the nested paths are preferred:

Legacy aliasCanonical V7 path
{{from.type}}{{from.element.types.[0]}}
{{from.captured.X}}{{from.element.captured.X}}
{{from.elementPath}}{{from.element.path}}
{{from.internalPath}}{{from.element.fileInternalPath}}
{{from.origin}}{{from.module.origin}}
{{from.parents.[0].type}}{{from.element.parents.[0].types.[0]}}
Deprecated

{{from.category}} / {{to.category}} resolve the deprecated element-level category field. They still work, but use file categories ({{from.file.categories}} / {{to.file.categories}}) instead. See the v6 to v7 migration guide.

Legacy Message Templates​

Legacy message template syntax using ${...} is kept for backward compatibility but is deprecated and will be removed in a future major version. Use Handlebars templates ({{...}}) instead.

It keeps working without changes, but using ${...} in a message now prints the same deprecation warning as legacy ${...} selectors. The boundaries/legacy-templates setting does not affect it — that setting only controls legacy templating in selectors, not the rendering of custom messages.

Backward Compatibility​

For backward compatibility, message rendering runs in two phases:

  1. Legacy replacement (${...}): Processes legacy template syntax with flattened property access
  2. Handlebars rendering ({{...}}): Processes modern template syntax with nested object access

This allows existing templates to continue working while you migrate to the new format.

Available properties​

Legacy templates do not support the full range of properties available in Handlebars templates. The following properties are available in legacy templates:

  • ${file.*} and ${dependency.*} - Legacy aliases for the importing/imported elements
    • type - Element type
    • internalPath - Path inside the element
    • source - Import source
    • importKind - Import kind (value, type, typeof)
    • All captured values from the element pattern
  • ${from.*} and ${target.*} - Alternative legacy aliases
  • ${file.parent.*}, ${from.parent.*}, ${dependency.parent.*}, ${target.parent.*} - Parent element properties
  • ${report.*} - Dependency metadata: ${report.path} is the target's internal path, ${report.specifiers} is the comma-separated list of imported specifiers

Example:

{
  "message": "${file.type} cannot import ${dependency.type}"
}

Migration to Handlebars​

To migrate from legacy templates to Handlebars:

  1. Replace ${...} with {{...}}: Change the delimiter syntax
  2. Update property paths: Use the new nested structure (from, to, dependency) instead of deprecated flattened aliases.
  3. Remove legacy aliases: Use official property names instead of deprecated aliases

Migration examples:

"${file.type} cannot import ${dependency.type}"
"{{from.element.types.[0]}} cannot import {{to.element.types.[0]}}"


"${file.type} with name ${file.elementName} cannot import ${dependency.family}"
"{{from.element.types.[0]}} with name {{from.element.captured.elementName}} cannot import {{to.element.captured.family}}"


"${file.type} in ${file.parent.type} cannot import ${dependency.type}"
"{{from.element.types.[0]}} in {{from.element.parents.[0].types.[0]}} cannot import {{to.element.types.[0]}}"
Migration Guide

For a detailed migration conversion table, see the v5 to v6 migration guide and the v6 to v7 migration guide.

See Also​