Support Inheriting ALCops Configuration from Remote "alcops.json" Configurations

[someC0d3r]

Background

The AL Language extension already allows RuleSets to be centralized across multiple repositories by referencing external RuleSet files.

With al.enableExternalRulesets enabled, a local RuleSet can include one or more external RuleSets. This makes it possible to maintain rule severities centrally: if a rule should be promoted from Warning to Error, for example, the change can be made once in the central RuleSet instead of updating every repository individually.

Use case for ALCops

I recently came across a similar use case with ALCops, specifically with LC0098 – Event subscriber name does not match the configured template.

The event subscriber naming convention can be configured through alcops.json, for example:

{
    "SubscriberNamingPattern": "{Event Source}_{Event Name}[_{Element Name}]"
}

However, if the same naming convention should apply to many repositories, the configuration currently needs to be added or changed separately in every repository.

For organizations maintaining a larger number of AL repositories, changing such a convention can therefore involve:

• creating a branch in every repository,
• updating alcops.json,
• creating a PR,
• reviewing and approving it, (also waiting for the pipeline run to finish)
• and finally merging it.

It would be useful if an alcops.json could inherit its configuration from a remote alcops.json, similar to external RuleSets in the AL Language extension.

For example:

{
    "InheritFromRemoteConfiguration": "https://example.com/alcops.config.json",
    "SubscriberNamingPattern": "{Event Source}_{Event Name}[_{Element Name}]"
}

Configuration precedence

My suggestion would be to treat the remote configuration as a base configuration and the local alcops.json as an override.

For example, if the remote configuration contains:

{
    "CognitiveComplexityThreshold": 15,
    "SubscriberNamingPattern": "{Event Source}_{Event Name}"
}

and the repository contains:

{
    "InheritFromRemoteConfiguration": "https://example.com/alcops.config.json",
    "SubscriberNamingPattern": "{Event Source}_{Event Name}[_{Element Name}]"
}

the effective configuration would be:

{
    "CognitiveComplexityThreshold": 15,
    "SubscriberNamingPattern": "{Event Source}_{Event Name}[_{Element Name}]"
}

In other words:

• If a setting is not specified locally, use the value from the inherited configuration.
• If a setting is specified locally, the local value takes precedence.

This would still allow repositories to deviate from the centralized configuration where necessary.

Multiple inherited configurations?

I'm not sure whether supporting multiple inherited configurations would provide enough additional value to justify the extra complexity.

Something similar to the AL Language extension could theoretically be supported:

{
    "InheritFromRemoteConfiguration": [
        "https://example.com/company.alcops.json",
        "https://example.com/team.alcops.json"
    ]
}

However, this would require defining clear precedence rules if the same setting is specified by multiple configurations, e.g. whether the first or last configuration wins.

For the initial implementation, supporting a single inherited configuration might therefore be sufficient and would keep the behavior straightforward.

Benefits

The main benefit would be centralized ALCops configuration across many repositories.

Changes to naming conventions, complexity thresholds, formatting preferences, or future ALCops configuration options could be rolled out centrally without having to modify every repository individually.

Repositories could still override individual settings when necessary, while common defaults remain maintained in one place.

What do you think about that?
... and can there be technical limitations regarding alc.exe?

[MODUSCarstenScholling]

I think this would be a useful addition for organizations maintaining multiple AL repositories. It allows common ALCops settings, such as naming patterns, complexity thresholds, and formatting preferences, to be maintained centrally while still allowing individual repositories to override specific values when needed.

Actually, I'm a little annoyed that I didn't come up with the idea myself. :)

The proposed configuration could use a dedicated Extends section:

{
  "Extends": {
    "Source": "https://example.com/company.alcops.json"
  },
  "SubscriberNamingPattern": "{Event Source}_{Event Name}[_{Element Name}]"
}

Extends expresses the intended behavior clearly: the referenced configuration provides a base, and the local alcops.json can override it. Using an object with Source also makes this directive visually distinct from normal analyzer settings and provides room for future metadata without changing the configuration shape again.

The effective configuration would be resolved as follows:

• The configuration referenced by Extends.Source is loaded as the base configuration.
• Locally specified settings take precedence over inherited settings.
• Nested objects are merged property by property, so a repository can override one nested setting without repeating the entire object.
• Arrays are replaced by the local value rather than merged, avoiding ambiguous ordering or duplicate behavior.

For the initial implementation, I would keep the scope deliberately limited:

• Support exactly one external configuration.
• Support anonymously accessible HTTP(S) URLs and absolute local file paths.
• Do not support inheritance chains. A referenced configuration must not itself declare Extends.

These restrictions keep precedence rules, caching, error handling, and diagnostics predictable. Different centrally managed configurations can simply be maintained as separate files.

There should be no fundamental limitation in alc.exe. ALCops can resolve the external configuration itself during settings loading.

The main operational consideration is network availability. The resolver should load the external configuration once per workspace path, use a short timeout, and fall back to the local configuration when the external source is unavailable or invalid. That keeps local development and CI builds functional even when the central configuration service cannot be reached.

A more general question in this matter:

Should ALCops report a configuration diagnostic whenever alcops.json or an external configuration cannot be read or parsed?

Currently, parsing errors are handled silently: invalid JSON, unknown enum values, or incompatible value types cause ALCops to fall back to the built-in default settings. When an external source cannot be read, is unavailable, or is invalid, ALCops ignores it and uses the local configuration instead.

[someC0d3r]

Thanks for your reply!
I like the idea of using an extends property. :-)

Should ALCops report a configuration diagnostic whenever alcops.json or an external configuration cannot be read or parsed?

In my opinion, a warning would be sufficient - but there should definitely be some kind of feedback for the user. Otherwise, they might assume that everything is working as expected while the external configuration is actually not being applied. :-/

Microsoft takes a somewhat stricter approach here and even reports an error when a remote ruleset cannot be loaded:
https://learn.microsoft.com/de-de/dynamics365/business-central/dev-itpro/developer/diagnostics/diagnostic-al1033?wt.mc_id=d365bc_inproduct_alextension

[someC0d3r]

I've set up Codex for the ALCops repositories and used it to create the following draft PRs:

• feat: support remote ALCops configuration #500
• docs: document external ALCops configuration alcops.dev#161

As a disclaimer:
I've also explicitly mentioned in the pull requests that they were created entirely using AI.

[MODUSCarstenScholling]

Looks good.
The only thing I would like to address in the implementation is the explicitly anonymous url. Your implementation seems to allow https://user:pass@... I would like you to block urls containing basic credentials (string.IsNullOrEmpty(uri.UserInfo)).

[someC0d3r]

Thanks for pointing this out:)

Here are the commits:

• Analyzer implementation and test: someC0d3r@d0b87a2
• Documentation update: someC0d3r/alcops.dev@c3f378b

Edit:
I've closed the Draft PRs so they don't appear in the PR list; you can still look into them and reopen by choice but they are currently only a PoC implementation for this suggestion, so thats why I don't want to bloat up the PR list.. :)