[Idea] Allow customALGoFiles.filesToInclude to override default AL-Go system file handling

[Florian (frottke)]

Idea Description

Allow customALGoFiles.filesToInclude to override default AL-Go system file handling

Current behavior

When using a custom template repository, workflow-specific settings files such as:

• .github/Test Next Minor.settings.json
• .github/Test Next Major.settings.json

are already included by the default AL-Go file configuration through:

@{ 'sourceFolder' = '.github'; 'filter' = '*.settings.json'; 'type' = 'settings' }

Because these files are handled as type = 'settings', an existing, non-empty settings file in the target repository is not fully synchronized with the corresponding file from the template. Only the $schema property is updated, while the remaining contents of the target file are preserved.

For example, the custom template may contain:

{
  "$schema": "...",
  "artifact": "////nextmajor",
  "cacheImageName": "",
  "versioningStrategy": 15,
  "vsixFile": "default"
}

while a repository using that template still contains:

{
  "$schema": "...",
  "artifact": "////nextmajor",
  "cacheImageName": "",
  "versioningStrategy": 15
}

Running Update AL-Go System Files does not add vsixFile.

Trying to explicitly include the file through customALGoFiles.filesToInclude also does not change this behavior:

"customALGoFiles": {
  "filesToInclude": [
    {
      "sourceFolder": ".github",
      "filter": "Test Next Minor.settings.json"
    },
    {
      "sourceFolder": ".github",
      "filter": "Test Next Major.settings.json"
    }
  ]
}

The default *.settings.json entry is resolved before the explicit customALGoFiles.filesToInclude entries. Since both resolve to the same destination path, the later explicit entry is treated as a duplicate and discarded.

As a result, it is currently not possible to use customALGoFiles.filesToInclude to opt selected settings files out of the default type = 'settings' behavior.

There is an additional consideration for custom template repositories: when the same file also exists in the original AL-Go template, the current source resolution may use the original template file as the synchronization source. Therefore, simply changing the order in which default and custom entries are processed would not necessarily make the file from the custom template authoritative.

Proposal

Allow explicit customALGoFiles.filesToInclude entries to override matching entries from the default AL-Go file configuration.

For a matching destination path, the explicit custom entry should:

1. take precedence over the corresponding default file configuration;
2. use the properties defined by the explicit entry rather than inheriting the default type, including treating the file as a normal synchronized file when no type is specified; and
3. use the file from the custom template repository as the synchronization source, rather than falling back to the corresponding file from the original AL-Go template.

In the example above, the explicit entries for:

• Test Next Minor.settings.json
• Test Next Major.settings.json

would therefore be synchronized as normal files from the custom template repository.

This would allow custom templates to fully manage selected workflow-specific settings files, including adding or removing properties such as vsixFile, while preserving the current default type = 'settings' behavior for all other *.settings.json files.

Contribution (Optional)

• I would be open to contributing to this idea (implementation, documentation, testing, etc.)