core
core copied to clipboard
Give errors on calls to client-only methods from server-side
WebSharper.JavaScript.Interop.X
should be considered client-only, as are all methods that has only this as body and all WIG methods. (Recursive exploration of further client-only methods are probably not a good idea, as they may call client-only code conditonally.)
Give an error when one of these are called from non-JavaScript
annotated code.
This analyzer could also treat IsClient
specially as in #730. Client-only calls in a false path would give a compile-time error.
@granicz @Jooseppi12 Additional ideas:
- The JavaScript attribute now has a constructor overload that takes a JavaScriptOptions enum for some rare use cases (optimized interface proxying in WS.Main, ignoring type lookup on defaultof). We can add a new flag here that also marks a module/class/member as client-only, it would look like:
[<JavaScript(JavaScriptOptions.ClientOnly>]
- As analyzing all calls in server-side+shared code for client-only calls to give errors takes some extra compilation time, we should make this feature optional too. As I don't think the performance hit could be substantial (linear checks only), my suggestion is to make it opt-out, in wsconfig.json:
clientOnlyErrors: false
while default is true. Equivalent project file property would be<WebSharperClientOnlyErrors>
- WIG should just mark whole assembly ClientOnly by default for simplicity, WIG dlls have no .NET implementations.
- We can still check for if method body is a single call to
WebSharper.JavaScript.Interop.X<_>
as in original idea and then mark as ClientOnly implicitly, makes updating WS core libraries for this feature much faster.