Application and Platform Dependency musst not be lower than any dependencies

[ChrisBlankDe]

App A v1 has Application 25.1
App A v2 has Application 25.2

App B has Application 25.2 and dependency to App A v1 -> warning occure
App B has Application 25.2 and dependency to App A v2 -> no warning occure

Theoretically, a newer version of App A can have a lower application dependency that the last version. However, most build systems and AppSource validation cannot handle this.

[rvanbekkum]

I think you could extend this to the "application", "platform" and "dependencies" versions must not be lower than those of any dependencies.

I think the challenging part is that you would need the exact versions of the apps you're taking a dependency on as symbols. During development I often have downloaded the symbols of newer versions of the apps that I am taking a dependency on, as the versions is the development Sandbox might be ahead.

I have already developed a rule for this, but have disabled the rule as I'm running into exactly this problem.
Do you have suggestions or thoughts on how to handle this problem?

[ChrisBlankDe]

"During development" - i am of the opinion that the output should be as close as possible to reality when developing. however, these are only hints.
the really important and relevant thing is what the build pipelines do. here you can ensure that the smallest possible dependency version is always used

the local development has a few inaccuracies, but in my opinion this is completely ok as long as the final validation is done by pipelines

[rvanbekkum]

Would you then put this as a rule that, for example, is Disabled (or Info) during local development, but Warning (or Error) during pipeline builds? To avoid confusion that way?

[ChrisBlankDe]

Personally, I would always leave it as a warning and explain to my developers why they can ignore it under certain circumstances.

By default, however, this should probably only be output as info in the linter cop because a rule violation has little/none functional impact.

[ernestasju]

Hi. I was about to write similar suggestion.

When a VS Code multi-root workspace has many apps and the .alpackages folder is shared between all of them, AL language extension can act a bit dumb - it can download too low extension version based on one app folder and then need higher extension version based on another app folder. This can sometimes lead to null reference exception during publish.

So, I usually add all workspace dependencies to the top level app and make sure those dependencies have versions greater or equal to those of dependency apps. I don't really have any scripts for checking this situation and it would be nice to have a analyzer warning about this case.

For example (assuming all apps are deployed together to all environments) (P.S. there are way more apps in our actual project):
Top level app - Bankfeed depends on Core >=v1.0, Provider1 >=v2.0, Provider2 >=v3.0, Library >=v1.0
Mid level app - Provider1 >=v2.0 depends on Core >=v1.0, Library >=v1.0
Mid level app - Provider2 >=v3.0 depends on Core >=v2.0, Library >=v3.0
Bottom level app - Core v2 depends on Library >=v1.0.

In this situation warnings should be shown for:
Bankfeed app because it should use Core >=v2.0 and Library >=v3.0.
Provider1 app because it should use Core >=v2.0 and Library >=v3.0.
Provider2 app because it should use Core >=v2.0 and Library >=v3.0.
Core app because it should use Library >=v3.0.

This analyzer should be hidden by default.

There is a tradeoff here because requiring to shift dependency versions up may require too high dependency versions that it is actually needed. E.g. warning says that app needs Core >=v3.0 while it could work perfectly fine with Core >=1.0. But assuming the workspace apps are deployed together you will have to use the newer version of dependency anyway since only a single app version can be installed at any given time.

We kinda could solve this right in newer apps using variables, but that would require a ton of work to rewrite all app.jsons of our many apps and making many Git commits. So maybe not right now. :)

Thanks.

CC @StefanMaron