Renovate Package Rules Guide

Table of Contents

1. What are Package Rules?

2. How Package Rules Work

3. Configuration Structure and Processing

4. Inherited Configuration Impact

5. Selectively Activating or Deactivating Renovate

6. Matching Criteria

7. Actions and Settings

8. Recommended Practices

9. Troubleshooting

What are Package Rules?

Package Rules in Renovate are powerful configuration objects that allow you to customize how Renovate behaves for specific packages, package types, or groups of dependencies. They provide fine-grained control over dependency updates by allowing you to:

• Apply different update strategies to different packages

• Group related dependencies together

• Set different schedules for different types of updates

• Customize automerge behavior

• Control versioning and branch strategies

• Apply specific labels, assignees, or reviewers

Think of package rules as conditional logic: "IF these conditions are met, THEN apply these settings."

This guide expands on the concepts described in the Renovate packageRules documentation.

How Package Rules Work

Package rules are evaluated during the dependency processing phase of Renovate's execution, specifically after dependency discovery but before PR/branch creation. Once Renovate completes discovery and extraction of dependencies from package files, it processes package rules using a matching system:

1. Matching Phase: Renovate evaluates each dependency against the matching criteria in your package rules

2. Application Phase: When a match is found, Renovate applies the specified configuration to that dependency

3. Precedence: Rules are processed in order, with later rules potentially overriding earlier ones

Configuration Structure and Processing

Package rules are defined in the packageRules array in your Renovate configuration.

Example:

{
  "packageRules": [
    {
      "matchDatasources": ["maven"],
      "matchManagers": ["maven-wrapper"],
      "registryUrls": ["<https://registry.mycompany.domain>"]
    }
  ]
}

Understanding the Implicit Structure

Unlike traditional programming languages with explicit if/then statements, Renovate package rules combine matching criteria and actions within the same object. This can be conceptually understood as conditional logic, but the syntax is more declarative.

How Properties Are Interpreted

Each package rule object contains a mix of:

• Matching criteria (what packages this rule applies to -- properties starting with match*) - the "IF" condition

• Configuration settings (what to do when matched -- all other properties) - the "THEN" action

{
  // 🔍 MATCHING CRITERIA (the "IF" part)
  "matchDatasources": ["maven"],
  "matchManagers": ["maven-wrapper"],
  
  // ⚙️ CONFIGURATION SETTINGS (the "THEN" part)  
  "registryUrls": ["<https://registry.mycompany.domain>"]
}

This translates to:

IF datasource is "maven" AND manager is "maven-wrapper"
THEN use the custom registry URL for package resolution

Multiple Conditions

When multiple matching criteria are present in the same rule, they are combined with AND logic

Structure Independence Inside Each Rule

Unlike traditional programming where IF conditions must come before THEN actions, packageRules properties can appear in any order within the object:

// ✅ Matching criteria first, then actions
{
  "matchDatasources": ["maven"],
  "matchManagers": ["maven-wrapper"],
  "registryUrls": ["<https://custom.registry.com>"]
}

// ✅ Actions first, then matching criteria  
{
  "registryUrls": ["<https://custom.registry.com>"],
  "matchDatasources": ["maven"],
  "matchManagers": ["maven-wrapper"]
}

// ✅ Mixed order
{
  "matchDatasources": ["maven"],
  "registryUrls": ["<https://custom.registry.com>"],
  "matchManagers": ["maven-wrapper"]
}

All three examples above are functionally identical. Renovate identifies matching criteria by property names (starting with match*) regardless of their position in the object.

💡 Readability Tip: While properties can appear in any order, mixing matching criteria and actions randomly can make packageRules harder to read and understand. Consider grouping matching criteria together (usually at the top) followed by configuration settings for better clarity.

Note that every package rule must include at least one matching criteria (a property starting with match*) AND at least one action property. A package rule without matching criteria or without any actions is considered invalid.

// ❌ INVALID - No matching criteria
{
  "packageRules": [
    {
      "groupName": "All updates",
      "automerge": true,
      "schedule": ["after 9pm"]
      // Missing any match* property - Renovate won't know which packages this applies to
    }
  ]
}

// ❌ INVALID - No action properties  
{
  "packageRules": [
    {
      "matchDepTypes": ["devDependencies"]
      // Missing action properties - Renovate won't know what to do when matched
    }
  ]
}

Processing Order

Rules are processed in order, with later rules potentially overriding earlier ones. Place general rules first and specific rules last to allow proper overriding:

{
  "packageRules": [
    // General rule first
    {
      "matchDepTypes": ["dependencies"],
      "separateMultipleMajor": true
    },
    // Specific rule last (overrides the general rule)
    {
      "matchPackageNames": ["lodash"],
      "separateMultipleMajor": false
    }
  ]
}

In this example:

1. The first rule tells Renovate to generate PRs for each major version available for all dependencies

2. The second rule overrides it to only generate one PRs for the latest major version of lodash available

No ELSE Construct

Unlike traditional programming, package rules have no explicit ELSE statement. Package rules are purely declarative and don't support conditional branching. However, you can achieve ELSE-like behavior as follows:

1. Rule Ordering and Default Behavior

Since later rules override earlier ones, you can create a complete conditional hierarchy using existing configurations and specific exceptions:

{
  "packageRules": [
    // Base configuration applies first (implicit ELSE):
    // - Renovate's built-in defaults
    // - Inherited configurations from organization config
    // - Extended presets (resolved before package rules)
    // - Other repository-level settings
    
    // Specific exception (IF case) - override base configuration where condition overlaps
    {
      "matchDepTypes": ["dependencies"],
      "commitMessagePrefix": "feat(deps):"
    },
    // Specific exception (IF case) - override settings above where conditions overlap
    {
      "matchManagers": ["dockerfile", "docker-compose"],
      "matchDatasources": ["docker"],
      "pinDigests": true
    },
    // Specific exception (IF case) - override settings above where condition overlaps
    {
      "matchPackageNames": ["express"],
      "allowedVersions": "<5.0.0"
    }   
  ]
}

This creates a complete conditional hierarchy:

• ELSE (Base configuration): All packages inherit settings from Renovate defaults, inherited config, extended presets, and other repository settings

• IF (Specific exceptions): Each IF condition overrides the base configuration and previous rules where match conditions overlap

2. Exclusion Patterns

Use negative regex patterns to handle wide "everything except" scenarios:

{
  "packageRules": [
    // Force dependency dashboard approval for every update EXCEPT for eslint and prettier packages
    {
      "matchPackageNames": ["!/^(eslint|prettier)$/"],
      "dependencyDashboardApproval": true
    }
  ]
}

The negative regex pattern !/^(eslint|prettier)$/ matches all packages except those that are exactly "eslint" or "prettier". The ! prefix creates a negative match condition.

⚠️ Exclusion Pattern Conflicts: Multiple package rules with exclusion patterns can conflict with each other, as later rules may overwrite settings from earlier ones. If you have overlapping exclusion patterns, the later rule will take precedence.

💡 Best Practice: Define exclusion pattern rules first in your packageRules array, before more specific rules. This allows specific rules to override the broad exclusion patterns when needed, preventing unexpected conflicts. See additional details here

Inherited Configuration Impact

When using Renovate in organizations, it's important to understand how inherited configurations affect package rule processing. Renovate processes configurations in a specific order: Global config → Inherited config → Resolved presets referenced in config → Repository config. This means that package rules defined in inherited config (typically from a centralized renovate-config repository) are merged and applied before your repository's local package rules are processed.

This has significant implications for rule precedence: if your organization's inherited config contains package rules, those rules will be evaluated first, and your repository's package rules can then override or extend them.

Additionally, presets referenced with extends are resolved first within each configuration level and take lower precedence than regular config in the same file. For example, if your repository config contains both extends presets and direct packageRules, the preset package rules are applied first, then your direct package rules can override them. However, you cannot use ignorePresets to ignore package rules that come from presets used in inherited config, as inherited config is resolved before repository config is processed.

Understanding this hierarchy is crucial for debugging unexpected behavior and designing effective package rule strategies across your organization.

Selectively Activating or Deactivating Renovate

Renovate allows you to control whether updates are enabled or disabled for specific dependencies or groups of dependencies using the enabled property within a package rule. This is useful when you want to temporarily or permanently exclude certain packages from being updated, or conversely, to re-enable updates for packages that may be disabled by default or by a broader rule.

How the enabled Property Works

• Setting "enabled": false in a package rule will deactivate Renovate updates for all dependencies that match the rule's criteria. Renovate will ignore these dependencies and will not create PRs or issues for them. Disabling updates this way does not uninstall or remove the dependency; it simply prevents Renovate from proposing updates for it.

• Setting "enabled": true (or omitting the property, as true is the default) will activate Renovate updates for the matched dependencies, unless another rule later in the list overrides this.

Example: Disabling Updates for a Group of Packages

{
  "packageRules": [
    {
      "description": "Disable updates for legacy packages",
      "matchPackageNames": ["/^legacy-lib.*/"],
      "enabled": false
    }
  ]
}

In this example, Renovate updates are disabled for any packages starting with 'legacy-lib'.

Example: Disabling Updates for All Packages, Then Enabling Specific Updates

{
  "packageRules": [
    {
      "description": "Disable updates for all packages",
      "matchPackageNames": [".*"],
      "enabled": false
    },
    {
      "description": "Enable updates for Docker packages only",
      "matchDatasources": ["docker"],
      "enabled": true
    }
  ]
}

In this example, Renovate updates are first disabled for all packages and then enabled specifically for any package that comes from the Docker datasource.

Use with caution: This approach restricts Renovate to only a subset of dependencies, which means you lose the main benefit of automated updates across your entire project. Consider whether you truly want to limit Renovate in this way, as it may leave many dependencies outdated and unmonitored.

Matching Criteria

Renovate provides numerous matching functions that allow you to target specific packages, files, or update types. Here's a complete list of all available matching criteria:

Complete List of Match Functions

Package Matching

• matchPackageNames (doc link) - Match exact package names (supports: exact, glob, regex, negation)

• matchDepNames (doc link) - Alternative name for matching package names (supports: exact, glob, regex, negation)

Dependency and Update Type Matching

• matchDepTypes (doc link) - Match by dependency type (supports: exact only)

• matchUpdateTypes (doc link) - Match by update type (supports: exact only)

• matchCurrentVersion (doc link) - Match packages with specific current versions (supports: exact, glob, regex)

• matchCurrentValue (doc link) - Match packages with specific current values (supports: exact, glob, regex)

• matchCurrentAge (doc link) - Match packages based on their current version age (supports: exact only - duration syntax)

• matchNewValue (doc link) - Match packages being updated to specific versions (supports: exact, glob, regex)

File Matching

• matchFileNames (doc link) - Match by file names (supports: exact, glob, regex)

Source and Manager Matching

• matchDatasources (doc link) - Match by package datasource (supports: exact only)

• matchManagers (doc link) - Match by package manager (supports: exact only)

• matchSourceUrls (doc link) - Match by source repository URL (supports: exact, glob, regex)

Repository and Branch Matching

• matchRepositories (doc link) - Match specific repositories (supports: exact, glob, regex)

• matchBaseBranches (doc link) - Match specific base branches (supports: exact, glob, regex)

Category and Confidence Matching

• matchCategories (doc link) - Match by package categories (supports: exact only)

• matchConfidence (doc link) - Match by update confidence levels (supports: exact only)

JSONata and Message Matching

• matchJsonata (doc link) - Match using JSONata query expressions (supports: JSONata syntax only)

• matchMessage (doc link) - Match by commit/PR message content (supports: exact, glob, regex)

💡 Some match functions perform their matching against the config object that is passed while processing the rules. This object is visible in the Renovate logs as "msg": "packageFiles with updates"

Commonly Used Match Functions

matchPackageNames

Match package names against packageName in config object (similar to matchDepNames - see here to understand the difference):

Available Syntax:

• Exact strings: "react", "@types/node"

• Regular expressions: /^@angular\\/.*/ (matches any Angular scoped package)

• Glob patterns: "eslint-*" (matches packages starting with "eslint-")

• Negation: "!/^@types\\/.*/" (matches all packages EXCEPT TypeScript type definitions)

{
  "matchPackageNames": ["@aws-sdk/*"],
  "groupName": "AWS SDK"
},
{
  "matchPackageNames": ["/eslint/", "prettier", "@typescript-eslint/*"],
  "groupName": "Linting tools"
}

This example groups all AWS SDK packages (using glob pattern) into a single PR. The second example groups ESLint-related packages (using a combination of patterns) together for easier management of linting tool updates.

matchDepTypes

Match by dependency type:

Supported matching: Exact strings only

{
  "matchDepTypes": ["dependencies"],
  "semanticCommitType": "build"
}

This example applies semantic commit type "build" to all production dependencies, helping maintain consistent commit message formatting for dependency updates that affect the build process.

Common dependency types:

• dependencies

• devDependencies

• peerDependencies

• optionalDependencies

• engines

matchCurrentAge

Match packages based on how old their current version is:

Supported matching: Duration syntax only

{
  "matchCurrentAge": "> 1 year",
  "addLabels": ["Old Dep Update"]
}

This example adds an "Old Dep Update" label to PRs for packages that haven't been updated in over a year, helping identify potentially stale dependencies that may need special attention.

Valid age operators: >, >=, <, <=, =
Valid time units: day(s), week(s), month(s), year(s)

matchNewValue

Match packages being updated to specific versions:

Supported matching: Exact, glob, and regex patterns

{
  "matchNewValue": "/^4\\./",
  "assignees": ["senior-dev"]
}

This example automatically assigns a senior developer to review any updates that involve upgrading to version 4.x, ensuring experienced oversight for potentially significant version changes.

matchUpdateTypes

Match by update type:

Supported matching: Exact strings only

{
  "matchUpdateTypes": ["major"],
  "dependencyDashboardApproval": true
}

This example requires manual approval through the dependency dashboard for all major version updates, providing a safety gate for potentially breaking changes before PRs are created.

Update types:

• major - Breaking changes (1.0.0 → 2.0.0)

• minor - New features (1.0.0 → 1.1.0)

• patch - Bug fixes (1.0.0 → 1.0.1)

• pin - Pinning versions

• digest - Docker image digest updates

• pinDigest - Pinning Docker image to specific SHA digests

• lockFileMaintenance - Maintenance updates performed periodically to refresh lock files

• rollback - Rollback to previous versions (when Renovate suggests reverting to an earlier version)

• bump - Dependency bumping - incremental updates in certain package managers (e.g., Go modules)

• replacement - Package replacement updates

⚠️ Note that matchUpdateTypes cannot be used in conjunction with any of the following actions:

• allowedVersions

• extractVersion

• followTag

• ignoreDeps

• ignoreUnstable

• rangeStrategy

• registryUrls

• respectLatest

• rollbackPrs

• separateMajorMinor

• separateMinorPatch

• separateMultipleMajor

• separateMultipleMinor

• versioning

matchFileNames

Match by file names (without paths):

Supported matching: Exact, glob, and regex patterns

{
  "matchFileNames": ["/__tests__/"],
  "enabled": false
}

This example disables Renovate updates for any files found in test directories (matching the /__tests__/ pattern), preventing unnecessary updates to test-specific dependencies that might not need regular maintenance.

matchDatasources

Match by package datasource:

Supported matching: Exact strings only

{
  "matchDatasources": ["docker"],
  "versioning": "loose"
}

This example applies loose versioning to all Docker images, which is useful when Docker tags don't follow strict semantic versioning conventions and need more flexible version comparison.

Common datasources: npm, docker, maven, pypi, nuget, github-releases, git-tags

matchManagers

Match by package manager:

Supported matching: Exact strings only

{
  "matchManagers": ["npm"],
  "rangeStrategy": "bump"
}

This example uses the "bump" range strategy for all npm packages, which updates version ranges (e.g., ^1.0.0 to ^1.1.0) rather than pinning to exact versions, maintaining flexibility in dependency resolution.

Common managers: npm, maven, dockerfile, docker-compose, pip_requirements, nuget, gradle

matchSourceUrls

Match by source repository URL:

Supported matching: Exact, glob, and regex patterns

{
  "matchSourceUrls": ["<https://github.com/facebook/react>"],
  "groupName": "React core"
}

This example groups all packages that originate from the React repository (react, react-dom, etc.) into a single "React core" PR, ensuring related packages are updated together.

matchCategories

Match by package categories:

Supported matching: Exact strings only

{
  "matchCategories": ["linting", "testing"],
  "automerge": true
}

This example enables automatic merging for packages categorized as linting or testing tools, since these updates typically have low risk and don't require manual review.

matchConfidence

Match by update confidence levels:

Supported matching: Exact strings only

{
  "matchConfidence": ["low"],
  "dependencyDashboardApproval": true
}

This example requires manual approval for updates with low confidence scores, adding an extra review step for potentially risky updates that Renovate's algorithms have flagged as uncertain.

ℹ️ This match type is only available in Renovate Enterprise Edition and Renovate bundled with Mend.io repo integration solutions

Confidence levels: low, neutral, high, very-high

matchJsonata

Use JSONata expressions for complex matching against the config object (advanced feature):

Supported matching: JSONata query language syntax only

{
  "matchJsonata": "currentVersion='1.0.0' and datasource='npm'",
  "enabled": false
}

This example uses JSONata to disable updates for npm packages that are currently at version 1.0.0, useful for freezing specific versions that might have known issues or compatibility requirements.

Complex JSONata example:

{
  "matchJsonata": "depType='dependencies' and currentVersionTimestamp < $now() - $duration('P3M')",
  "prPriority": 10
}

This advanced example uses JSONata to match production dependencies whose current version is older than 3 months, then assigns them high priority (10) to ensure older dependencies get updated first.

Note: JSONata is an advanced query language - see JSONata documentation for syntax details.

Actions and Settings

Once a package rule matches, you can apply various configuration settings to control what Renovate needs to do with those packages.

Renovate provides an extensive set of configuration settings available in the official configuration documentation. You can use most Renovate repository configuration options as actions within package rules (unless explicitly stated not to).

How to determine if an option should not be used in package rules:

• Global repository settings - Options that affect the entire Renovate run (baseBranches, enabledManagers, mode, etc.)

• Authentication/host settings - Options for credentials and registry access (hostRules, npmToken, etc.)

When in doubt, consider: "Does this setting make sense applied to individual packages vs. the entire repository?" If it's package-specific, it can likely be used in package rules.

Commonly used actions and settings

The list below covers the most commonly used actions and settings in package rules. Click on each documentation link to learn more details.

Grouping and Organization

• groupName (doc link) - Group multiple related packages into a single PR to reduce noise and ensure coordinated updates of interdependent packages.

• groupSlug (doc link) - Customize the branch name slug for grouped updates, allowing for more readable and organized branch naming conventions

• separateMajorMinor (doc link) - Separate major and minor version updates into different PRs to allow different review processes for breaking vs non-breaking changes

• separateMultipleMajor (doc link) - Create separate PRs for each available major version update instead of jumping to the latest, enabling gradual migration paths

• description (doc link) - Add human-readable descriptions to package rules for better documentation and maintainability of configuration

Automerge Configuration

• automerge (doc link) - Enable automatic merging of PRs when all conditions are met, reducing manual intervention for low-risk updates

• automergeType (doc link) - Specify merge strategy: 'pr' creates a PR then merges, 'branch' merges directly, 'pr-comment' merges via comment

Scheduling and Timing

• schedule (doc link) - Control when updates are created using cron-like syntax to avoid disrupting business hours or coordinate with deployment windows

• minimumReleaseAge (doc link) - Set minimum age requirement for releases to be considered, helping avoid unstable or quickly-retracted versions

Version and Range Management

• rangeStrategy (doc link) - Control how version ranges are updated: pin to exact versions, bump ranges, replace ranges, or widen constraints

• versioning (doc link) - Specify versioning scheme (semver, loose, node, etc.) to handle different package ecosystems' version numbering conventions

• allowedVersions (doc link) - Restrict allowed versions using regex patterns or ranges to avoid problematic versions or enforce version policies

Commit Configuration

• commitMessagePrefix (doc link) - Prefix for commit messages to categorize updates and integrate with semantic commit conventions

• commitBody (doc link) - Custom commit body template to include detailed information about the update in the commit description

• semanticCommitType (doc link) - Type for semantic commits (feat, fix, chore, etc.) to categorize dependency updates appropriately

• semanticCommitScope (doc link) - Scope for semantic commits to specify the area or component affected by the dependency update

Pull Request Configuration

• prBodyNotes (doc link) - Additional notes for PR body to provide context, warnings, or special instructions for specific updates

• prCreation (doc link) - Control when PRs are created: immediately, not-pending, or approval-required for different update strategies

Labels, Assignees, and Reviewers

• labels (doc link) - Add labels to PRs for categorization, filtering, and integration with project management workflows

• addLabels (doc link) - Additional labels to add on top of existing labels, useful for supplementing default labeling schemes

• assignees (doc link) - Assign PRs to specific people or teams responsible for reviewing and merging dependency updates

• reviewers (doc link) - Add specific reviewers to PRs to ensure appropriate expertise and oversight for dependency changes

• additionalReviewers (doc link) - Additional reviewers to add beyond the standard reviewer list for extra oversight on critical updates

Update Limits and Throttling

• prConcurrentLimit (doc link) - Limit concurrent PRs to prevent overwhelming teams and CI/CD systems with too many simultaneous updates

• prHourlyLimit (doc link) - Limit PRs per hour to control the rate of updates and avoid notification spam or system overload

• prPriority (doc link) - Set PR priority to influence the order in which Renovate processes and creates pull requests

Package Management

• enabled (doc link) - Enable/disable updates for matched packages to selectively control which dependencies Renovate manages

• registryUrls (doc link) - Custom registry URLs for private registries, mirrors, or alternative package sources

• abandonmentThreshold (doc link) - Set the threshold for when a package should be considered abandoned based on time since last release

• pinDigests (doc link) - Pin Docker image tags to specific SHA digests for enhanced security and reproducibility

• dependencyDashboardApproval (doc link) - Require manual approval via dependency dashboard before creating PRs

Recommended Practices

Package rules are one of Renovate's most powerful features, allowing you to create sophisticated dependency update strategies tailored to your project's needs. Start with simple rules and gradually build more complex configurations as you become familiar with how the rules are applied.
In general, Renovate is designed to work well with its default values and requires minimal configuration for most use cases. For additional recommended settings beyond the defaults, consider extending from the config:best-practices preset, which includes many carefully curated package rules developed and maintained by the Renovate team:

{
  "extends": ["config:best-practices"]
}

This preset can serve as an excellent starting point or complement to your custom package rules.

Additional Recommendations

1. Use Descriptive Names

Always include descriptions for your rules:

{
  "description": "Automerge patch updates for dev dependencies to reduce noise",
  "matchDepTypes": ["devDependencies"],
  "matchUpdateTypes": ["patch"],
  "automerge": true
}

2. Group Related Updates

Group packages that should be updated together:

{
  "matchDatasources": [
    "docker"
  ],
  "matchPackageNames": [
    "mcr.microsoft.com/dotnet/**"
  ],
  "groupName": ".NET Core Docker containers"
}

💡 Note: Package grouping is one of the most effective noise reduction strategies, but should be used thoughtfully. While grouping reduces PR volume and ensures coordinated updates, it can increase the chance of build failures and make it harder to identify which specific package caused issues. Consider the trade-offs between reduced noise and easier troubleshooting when designing your grouping strategy.

3. Test Automerge Carefully

Start with low-risk packages for automerge:

{
  "packageRules": [
    {
      "description": "Safe automerge for Python style guide patch updates",
      "matchPackageNames": ["flake8"],
      "matchUpdateTypes": ["patch"],
      "automerge": true
    }
  ]
}

4. Use Selective Enabling/Disabling Thoughtfully

When using the enabled property to control which packages are updated:

• Use enabled: false to exclude packages that are deprecated, managed manually, or should not be updated for business reasons

• Place more general disabling rules first, and more specific enabling rules later, to ensure the correct precedence

{
  "packageRules": [
    {
      "description": "Disable updates for legacy packages",
      "matchPackageNames": ["/^legacy-lib.*/"],
      "enabled": false
    },
    {
      "description": "Re-enable updates for specific legacy package that's still maintained",
      "matchPackageNames": ["legacy-lib-core"],
      "enabled": true
    }
  ]
}

Troubleshooting

Common Issues and Solutions

1. Rules Not Applying

Problem: Package rules seem to be ignored due to later rules with negative patterns overriding earlier ones.
Solution: Check rule order and be aware of how negative patterns in later rules can exclude packages from earlier rules.

// ❌ Problematic - the second rule's negative pattern matches testing packages, overriding first rule
{
  "packageRules": [
    {
      "matchPackageNames": ["jest", "mocha", "chai", "cypress"],
      "matchUpdateTypes": ["patch"],
      "automerge": true
    },
    {
      "matchPackageNames": ["!/^(eslint|prettier)$/"],
      "automerge": false
    }
  ]
}

// ✅ Correct - reorder rules
{
  "packageRules": [
    {
      "description": "Disable automerge for all packages except linting tools",
      "matchPackageNames": ["!/^(eslint|prettier)$/"], 
      "automerge": false
    },
    {
      "description": "Automerge patch updates for testing packages",
      "matchPackageNames": ["jest", "mocha", "chai", "cypress"],
      "matchUpdateTypes": ["patch"],
      "automerge": true
    }
  ]
}

2. Conflicting Rules

Problem: Multiple rules conflict with each other.
Solution: Use more specific matching or reorder rules. Remember that later rules override earlier ones.

// ❌ Wrong - unintended override due to rule order
{
  "packageRules": [
    {
      "matchPackageNames": ["react"],
      "branchPrefix": "feature/react-"
    },
    {
      "matchDepTypes": ["dependencies"],
      "branchPrefix": "deps/"
    }
  ]
}

// ✅ Correct - specific rule comes after general rule
{
  "packageRules": [
    // General rule first
    {
      "matchDepTypes": ["dependencies"],
      "branchPrefix": "deps/"
    },
    // Specific exception last (overrides the general rule)
    {
      "matchPackageNames": ["react"],
      "branchPrefix": "feature/react-"
    }
  ]
}

3. Regex Pattern Issues

Problem: Package patterns don't match expected packages due to incorrect regex syntax.
Solution: Follow proper regex syntax requirements and escape special characters. See string pattern matching documentation for details.

// ❌ Wrong - invalid regex syntax (missing slashes) and unescaped dots
{
  "matchPackageNames": ["@company.internal.*"]
}

// ❌ Wrong - case sensitive regex won't match mixed case package names
{
  "matchPackageNames": ["/^@AWS-SDK/"]
}

// ✅ Correct - proper regex syntax with escaped dots
{
  "matchPackageNames": ["/^@company\\.internal\\./"]
}

// ✅ Correct - case insensitive regex using /i flag
{
  "matchPackageNames": ["/^@aws-sdk/i"]
}