Communication practices with the developer?

[Thorium]

This is not a single issue, rather question of design guidelines.

The modern type-providers are evolving into more and more complex tools, almost like production ready platforms, than a single-datasource-model-generators. That's kind of sad, but on the other hand, the world has went to this python&javascript-everything, so something giving you strong typing is still a glimmer of hope. Also command-line tools are back, text-based interfaces are not hated.

Are there best practices, how should type-providers do the communication with the developer?
I think there are some common areas of problems where FSharp.TypeProviders.SDK could help guiding common approaches to do things.

Maybe @pezipink was onto something here when he created typeproviders that interacted their state with the developer via intellisense.

Here are listed some typical scenarios:

Please, set some state with the parameters

Typically static parameters, but what if an enum is not enough?
The optimal case would be sending a DU to the typeprovider. But the static parameters have to be literals, they can't be DUs.

• Should we go into the endless world of string-parsing, exposing possible injection-vulnerabilities?
• Should we could create myType.``Design Time Methods``.someAction(paramsHere)
• Or should we create a lot of different type-providers per the same NuGet-package?

Fatal error, like a network error, please retry

Errors are usually thrown on the TP creation level, the root-type will give red underline and tool-tip.
This is not the most convenient for the user, typically you'd like to google the error message, but how do you copy-paste from the tool-tip, so you have to know to build on the command line to get the error.
Also proper caching is kind of common issue with all the providers: Developer IDE has multiple threads and tries to get the original data source multiple times, you'd like to use some lazy concurrent dictionary but avoid caching the exceptions... Easily done wrong, a common thing, should be dealt on provider SDK level, not by each provider themselves.

We identified minor issues with the schema.

There is no easy way to show warnings to the user.
There is no easy way to do logging.

If we throw error, it means the provider is un-usable.
So should we use events and expect the user would listen something?
Or should we serialize some property that the user would actually find somehow?
Like a "SchemaErrors" or "TypeProviderErrors" or something?
There is an open issue.

Sorry, the loading taking longer than expected, but is still going on...

How to see that something is going on or not ready?
Could there be a temporary .``Loading...`` property?
Could async be utilised better?