[Suggestion / Question] Managing codeCleanupActions settings on a central location?

[fvet]

As AZ AL Dev Tools continuously provides new Code Cleanup Actions (which is great !), I often have to keep our repo settings up to date by adding these new options (only those we want to implement) to the alOutline.codeCleanupActions setting. Settings are maintained per folder / app, not on user level.

However, as the number of repo's / apps keeps growing, I was thinking to maintain the settings on a more central level, so they can be shared across all repo's.

I do like the externalruleset support from the cops, so we can manage our global 'company' rulesets on a central (e.g. azure blob) location, so they are automatically applied on all repo's referencing this ruleset.

Is there any setting in VS code that (besides user / folder / workspace settings) allows to 'import' certain (global company) settings (alOutline.codeCleanupActions + maybe some related ones) and apply on top of the current ones?

Related link? https://github.com/microsoft/vscode/issues/15909

[anzwdev]

I don't think that there is anything in VS Code that could allow you to have global settings loaded from shared folder :(

It is interesting idea, but remember that having shared, global settings has also some disadvantages. Imagine that you have a lot of repositories with tested extensions running in the customer production databases. Everything is fine, customers are happy. At some point you decide to change these global settings. Then a few days later there is a problem with one of these extensions, customer cannot work and you need to fix it. The fix could be just one line, but because global settings have been changes, you now have a lot of additional warnings/errors to fix. Having settings per repository allows you to decide when you want to update them and refactor code instead of being to forced to do it at the worst moment when there is a bug in customer system, they cannot work and you are expected to fix problem as fast as you can.

[fvet]

Rules I agree with above remark, but this is right now also the consequence of using externalrulesets. If we agree on company level to apply a new rule, we would like to inform all projects to start adopting the new rules (by adjusting the externalruleset). As most rules are mainly introduced via new AL runtime versions, they will only appear / be applied when upgrading the customer to the next major, not during hotfix periods.

Code cleanup actions The AZ AL Dev Tools codeCleanupActions are somewhat less intrusive as they are mainly semantical / (almost) non-breaking. Developers can always opt to skip the 'Cleanup' action, as no warnings arise.

I'll let it up to you to close this issue ... :)

[anzwdev]

I will leave it open and think about a solution. I don't want to create tool that works with a single scenario only.

If global setting is something that works for somebody, then it might be an interesting idea, but that person should also be aware that it could cause problems in some cases.