Misleading diagnostic ordering when resolving packages #37193
Labels
Area/Diagnostics
Issues related Diagnostics reported by the Compiler. #Compiler
Area/ProjectAPI
Team/DevTools
Ballerina Developer Tooling ( CLI, Test FW, Package Management, OpenAPI, APIDocs )
Type/Improvement
Consider a scenario where I have specified a package version in the Ballerina.toml which is not available locally, but I have included the property
repository=local
. e.g.,In the above case,
0.3.3
is not available locally but it is there in Central. When I run the package, I get the following:Although there was this warning, it ran without any issue. The ordering of the events/diagnostics is a bit confusing here. When I saw that the package was pulled successfully, the expectation was that now it's available locally (it was available now). But when the compiler gave the warning about not being able to find the package locally, I thought there must've been something wrong in pulling the package or that the package wasn't getting resolved properly.
Had a chat with @azinneera and she pointed out that it's just that the diagnostic is getting printed later. It would be better if these sort of diagnostics are printed first, before attempting to pull the package from Central. e.g.,
Basically the requirement is, clearly communicate to the user that it'll try and fetch the package from Central if it's not available locally.
The text was updated successfully, but these errors were encountered: