WoofWare.Myriad.Plugins.Attributes
2.0.5
See the version list below for details.
dotnet add package WoofWare.Myriad.Plugins.Attributes --version 2.0.5
NuGet\Install-Package WoofWare.Myriad.Plugins.Attributes -Version 2.0.5
<PackageReference Include="WoofWare.Myriad.Plugins.Attributes" Version="2.0.5" />
paket add WoofWare.Myriad.Plugins.Attributes --version 2.0.5
#r "nuget: WoofWare.Myriad.Plugins.Attributes, 2.0.5"
// Install WoofWare.Myriad.Plugins.Attributes as a Cake Addin #addin nuget:?package=WoofWare.Myriad.Plugins.Attributes&version=2.0.5 // Install WoofWare.Myriad.Plugins.Attributes as a Cake Tool #tool nuget:?package=WoofWare.Myriad.Plugins.Attributes&version=2.0.5
WoofWare.Myriad.Plugins
Some helpers in Myriad which might be useful.
These are currently somewhat experimental, and I personally am their primary customer.
The RemoveOptions
generator in particular is extremely half-baked.
If you would like to ensure that your particular use-case remains unbroken, please do contribute tests to this repository.
The ConsumePlugin
assembly contains a number of invocations of these source generators,
so you just need to add copies of your types to that assembly to ensure that I will at least notice if I break the build;
and if you add tests to WoofWare.Myriad.Plugins.Test
then I will also notice if I break the runtime semantics of the generated code.
Currently implemented:
JsonParse
(to stamp outjsonParse : JsonNode -> 'T
methods);JsonSerialize
(to stamp outtoJsonNode : 'T -> JsonNode
methods);RemoveOptions
(to stripoption
modifiers from a type).HttpClient
(to stamp out a RestEase-style HTTP client).GenerateMock
(to stamp out a record type corresponding to an interface).
JsonParse
Takes records like this:
[<WoofWare.Myriad.Plugins.JsonParse>]
type InnerType =
{
[<JsonPropertyName "something">]
Thing : string
}
/// My whatnot
[<WoofWare.Myriad.Plugins.JsonParse>]
type JsonRecordType =
{
/// A thing!
A : int
/// Another thing!
B : string
[<System.Text.Json.Serialization.JsonPropertyName "hi">]
C : int list
D : InnerType
}
and stamps out parsing methods like this:
/// Module containing JSON parsing methods for the InnerType type
[<RequireQualifiedAccess>]
[<CompilationRepresentation(CompilationRepresentationFlags.ModuleSuffix)>]
module InnerType =
/// Parse from a JSON node.
let jsonParse (node: System.Text.Json.Nodes.JsonNode) : InnerType =
let Thing = node.["something"].AsValue().GetValue<string>()
{ Thing = Thing }
namespace UsePlugin
/// Module containing JSON parsing methods for the JsonRecordType type
[<RequireQualifiedAccess>]
[<CompilationRepresentation(CompilationRepresentationFlags.ModuleSuffix)>]
module JsonRecordType =
/// Parse from a JSON node.
let jsonParse (node: System.Text.Json.Nodes.JsonNode) : JsonRecordType =
let D = InnerType.jsonParse node.["d"]
let C =
node.["hi"].AsArray() |> Seq.map (fun elt -> elt.GetValue<int>()) |> List.ofSeq
let B = node.["b"].AsValue().GetValue<string>()
let A = node.["a"].AsValue().GetValue<int>()
{ A = A; B = B; C = C; D = D }
You can optionally supply the boolean true
to the attribute,
which will cause Myriad to stamp out an extension method rather than a module with the same name as the type.
This is useful if you want to reuse the type name as a module name yourself,
or if you want to apply multiple source generators which each want to use the module name.
What's the point?
System.Text.Json
, in a PublishAot
context, relies on C# source generators.
The default reflection-heavy implementations have the necessary code trimmed away, and result in a runtime exception.
But C# source generators are entirely unsupported in F#.
This Myriad generator expects you to use System.Text.Json
to construct a JsonNode
,
and then the generator takes over to construct a strongly-typed object.
Limitations
This source generator is enough for what I first wanted to use it for. However, there is far more that could be done.
- Make it possible to give an exact format and cultural info in date and time parsing.
- Make it possible to reject parsing if extra fields are present.
- Generally support all the
System.Text.Json
attributes.
For an example of using both JsonParse
and JsonSerialize
together with complex types, see the type definitions and tests.
JsonSerialize
Takes records like this:
[<WoofWare.Myriad.Plugins.JsonSerialize true>]
type InnerTypeWithBoth =
{
[<JsonPropertyName("it's-a-me")>]
Thing : string
ReadOnlyDict : IReadOnlyDictionary<string, Uri list>
}
and stamps out modules like this:
module InnerTypeWithBoth =
let toJsonNode (input : InnerTypeWithBoth) : System.Text.Json.Nodes.JsonNode =
let node = System.Text.Json.Nodes.JsonObject ()
do
node.Add (("it's-a-me"), System.Text.Json.Nodes.JsonValue.Create<string> input.Thing)
node.Add (
"ReadOnlyDict",
(fun field ->
let ret = System.Text.Json.Nodes.JsonObject ()
for (KeyValue (key, value)) in field do
ret.Add (key.ToString (), System.Text.Json.Nodes.JsonValue.Create<Uri> value)
ret
) input.Map
)
node
As in JsonParse
, you can optionally supply the boolean true
to the attribute,
which will cause Myriad to stamp out an extension method rather than a module with the same name as the type.
The same limitations generally apply to JsonSerialize
as do to JsonParse
.
For an example of using both JsonParse
and JsonSerialize
together with complex types, see the type definitions and tests.
RemoveOptions
Takes a record like this:
type Foo =
{
A : int option
B : string
C : float list
}
and stamps out a record like this:
[<RequireQualifiedAccess>]
module Foo =
type Short =
{
A : int
B : string
C : float list
}
What's the point?
The motivating example is argument parsing. An argument parser naturally wants to express "the user did not supply this, so I will provide a default". But it's not a very ergonomic experience for the programmer to deal with all these options, so this Myriad generator stamps out a type without any options, and also stamps out an appropriate constructor function.
Limitations
This generator is far from where I want it, because I haven't really spent any time on it.
- It really wants to be able to recurse into the types within the record, to strip options from them.
- It needs some sort of attribute to mark a field as not receiving this treatment.
- What do we do about discriminated unions?
HttpClient
Takes a type like this:
[<WoofWare.Myriad.Plugins.HttpClient>]
type IPureGymApi =
[<Get "v1/gyms/">]
abstract GetGyms : ?ct : CancellationToken -> Task<Gym list>
[<Get "v1/gyms/{gym_id}/attendance">]
abstract GetGymAttendance : [<Path "gym_id">] gymId : int * ?ct : CancellationToken -> Task<GymAttendance>
[<Get "v1/member">]
abstract GetMember : ?ct : CancellationToken -> Task<Member>
[<Get "v1/gyms/{gym_id}">]
abstract GetGym : [<Path "gym_id">] gymId : int * ?ct : CancellationToken -> Task<Gym>
[<Get "v1/member/activity">]
abstract GetMemberActivity : ?ct : CancellationToken -> Task<MemberActivityDto>
[<Get "v2/gymSessions/member">]
abstract GetSessions :
[<Query>] fromDate : DateTime * [<Query>] toDate : DateTime * ?ct : CancellationToken -> Task<Sessions>
and stamps out a type like this:
/// Module for constructing a REST client.
[<CompilationRepresentation(CompilationRepresentationFlags.ModuleSuffix)>]
[<RequireQualifiedAccess>]
module PureGymApi =
/// Create a REST client.
let make (client : System.Net.Http.HttpClient) : IPureGymApi =
{ new IPureGymApi with
member _.GetGyms (ct : CancellationToken option) =
async {
let! ct = Async.CancellationToken
let httpMessage =
new System.Net.Http.HttpRequestMessage (
Method = System.Net.Http.HttpMethod.Get,
RequestUri = System.Uri (client.BaseAddress.ToString () + "v1/gyms/")
)
let! response = client.SendAsync (httpMessage, ct) |> Async.AwaitTask
let response = response.EnsureSuccessStatusCode ()
let! stream = response.Content.ReadAsStreamAsync ct |> Async.AwaitTask
let! node =
System.Text.Json.Nodes.JsonNode.ParseAsync (stream, cancellationToken = ct)
|> Async.AwaitTask
return node.AsArray () |> Seq.map (fun elt -> Gym.jsonParse elt) |> List.ofSeq
}
|> (fun a -> Async.StartAsTask (a, ?cancellationToken = ct))
// (more methods here)
}
What's the point?
The motivating example is again ahead-of-time compilation: we wish to avoid the reflection which RestEase does.
Features
- Variable and constant header values are supported:
see the definition of
IApiWithHeaders
.
Limitations
RestEase is complex, and handles a lot of different stuff.
- If you set the
BaseAddress
on your inputHttpClient
, make sure to end with a trailing slash on any trailing directories (so"blah/foo/"
rather than"blah/foo"
). We combine URIs usingUriKind.Relative
, so without a trailing slash, the last component may be chopped off. - Parameters are serialised naively with
toJsonNode
as though theJsonSerialize
generator were applied, and you can't control the serialisation. You can't yet serialise e.g. a primitive type this way (other thanString
); all body parameters must be types which have a suitabletoJsonNode : 'a -> JsonNode
method. - Deserialisation follows the same logic as the
JsonParse
generator, and it generally assumes you're using types whichJsonParse
is applied to. - Anonymous parameters are currently forbidden.
There are also some design decisions:
- Every function must take an optional
CancellationToken
(which is good practice anyway); so arguments are forced to be tupled. - The
[<Optional>]
attribute is not supported and will probably not be supported, because I consider it to be cursed.
GenerateMock
Takes a type like this:
[<GenerateMock>]
type IPublicType =
abstract Mem1 : string * int -> string list
abstract Mem2 : string -> int
and stamps out a type like this:
/// Mock record type for an interface
type internal PublicTypeMock =
{
Mem1 : string * int -> string list
Mem2 : string -> int
}
static member Empty : PublicTypeMock =
{
Mem1 = (fun x -> raise (System.NotImplementedException "Unimplemented mock function"))
Mem2 = (fun x -> raise (System.NotImplementedException "Unimplemented mock function"))
}
interface IPublicType with
member this.Mem1 (arg0, arg1) = this.Mem1 (arg0, arg1)
member this.Mem2 (arg0) = this.Mem2 (arg0)
What's the point?
Reflective mocking libraries like Foq in my experience are a rich source of flaky tests. The Grug-brained developer would prefer to do this without reflection, and this reduces the rate of strange one-in-ten-thousand "failed to generate IL" errors. But since F# does not let you partially update an interface definition, we instead stamp out a record, thereby allowing the programmer to use F#'s record-update syntax.
Limitations
- We make the resulting record type at most internal (never public), since this is intended only to be used in tests.
You will therefore need an
AssemblyInfo.fs
file like the one in WoofWare.Myriad's own tests.
Detailed examples
See the tests. For example, PureGymDto.fs is a real-world set of DTOs.
How to use
- In your
.fsproj
file, define a helper variable so that subsequent steps don't all have to be kept in sync:<PropertyGroup> <WoofWareMyriadPluginVersion>2.0.1</WoofWareMyriadPluginVersion> </PropertyGroup>
- Take a reference on
WoofWare.Myriad.Plugins.Attributes
(which has no other dependencies), to obtain access to the attributes which the generator will recognise:<ItemGroup> <PackageReference Include="WoofWare.Myriad.Plugins.Attributes" Version="2.0.2" /> </ItemGroup>
- Take a reference (with private assets, to prevent these from propagating to your own assembly) on
WoofWare.Myriad.Plugins
, to obtain the plugins which Myriad will run, and onMyriad.Sdk
, to obtain the Myriad binary itself:<ItemGroup> <PackageReference Include="WoofWare.Myriad.Plugins" Version="$(WoofWareMyriadPluginVersion)" PrivateAssets="all" /> <PackageReference Include="Myriad.Sdk" Version="0.8.3" PrivateAssets="all" /> </ItemGroup>
- Point Myriad to the DLL within the NuGet package which is the source of the plugins:
<ItemGroup> <MyriadSdkGenerator Include="$(NuGetPackageRoot)/woofware.myriad.plugins/$(WoofWareMyriadPluginVersion)/lib/net6.0/WoofWare.Myriad.Plugins.dll" /> </ItemGroup>
Now you are ready to start using the generators.
For example, this specifies that Myriad is to use the contents of Client.fs
to generate the file GeneratedClient.fs
:
<ItemGroup>
<Compile Include="Client.fs" />
<Compile Include="GeneratedClient.fs">
<MyriadFile>Client.fs</MyriadFile>
</Compile>
</ItemGroup>
Myriad Gotchas
- MsBuild doesn't always realise that it needs to invoke Myriad during rebuild.
You can always save a whitespace change to the source file (e.g.
Client.fs
above), and MsBuild will then execute Myriad during the next build. - Fantomas, the F# source formatter which powers Myriad, is customisable with editorconfig, but it does not easily expose this customisation except through the standalone Fantomas client. So Myriad's output is formatted without respect to any conventions which may hold in the rest of your repository. You should probably add these files to your fantomasignore if you use Fantomas to format your repo; the alternative is to manually reformat every time Myriad changes the generated files.
Product | Versions Compatible and additional computed target framework versions. |
---|---|
.NET | net5.0 was computed. net5.0-windows was computed. net6.0 was computed. net6.0-android was computed. net6.0-ios was computed. net6.0-maccatalyst was computed. net6.0-macos was computed. net6.0-tvos was computed. net6.0-windows was computed. net7.0 was computed. net7.0-android was computed. net7.0-ios was computed. net7.0-maccatalyst was computed. net7.0-macos was computed. net7.0-tvos was computed. net7.0-windows was computed. net8.0 was computed. net8.0-android was computed. net8.0-browser was computed. net8.0-ios was computed. net8.0-maccatalyst was computed. net8.0-macos was computed. net8.0-tvos was computed. net8.0-windows was computed. |
.NET Core | netcoreapp2.0 was computed. netcoreapp2.1 was computed. netcoreapp2.2 was computed. netcoreapp3.0 was computed. netcoreapp3.1 was computed. |
.NET Standard | netstandard2.0 is compatible. netstandard2.1 was computed. |
.NET Framework | net461 was computed. net462 was computed. net463 was computed. net47 was computed. net471 was computed. net472 was computed. net48 was computed. net481 was computed. |
MonoAndroid | monoandroid was computed. |
MonoMac | monomac was computed. |
MonoTouch | monotouch was computed. |
Tizen | tizen40 was computed. tizen60 was computed. |
Xamarin.iOS | xamarinios was computed. |
Xamarin.Mac | xamarinmac was computed. |
Xamarin.TVOS | xamarintvos was computed. |
Xamarin.WatchOS | xamarinwatchos was computed. |
-
.NETStandard 2.0
- FSharp.Core (>= 4.3.4)
NuGet packages (2)
Showing the top 2 NuGet packages that depend on WoofWare.Myriad.Plugins.Attributes:
Package | Downloads |
---|---|
WoofWare.Myriad.Plugins
Provides some Myriad compile-time code generation plugins. |
|
WoofWare.NUnitTestRunner.Lib
Library with primitives to allow you to run NUnit tests. |
GitHub repositories
This package is not used by any popular GitHub repositories.
Version | Downloads | Last updated |
---|---|---|
3.6.4 | 255 | 10/21/2024 |
3.6.3 | 423 | 10/2/2024 |
3.6.2 | 361 | 9/19/2024 |
3.6.1 | 251 | 9/15/2024 |
3.5.1 | 225 | 9/11/2024 |
3.4.1 | 268 | 9/5/2024 |
3.3.1 | 136 | 9/4/2024 |
3.2.3 | 159 | 9/4/2024 |
3.2.2 | 161 | 9/2/2024 |
3.2.1 | 376 | 8/26/2024 |
3.1.12 | 399 | 8/12/2024 |
3.1.11 | 176 | 8/4/2024 |
3.1.10 | 80 | 8/4/2024 |
3.1.9 | 356 | 7/8/2024 |
3.1.8 | 322 | 7/1/2024 |
3.1.7 | 736 | 6/17/2024 |
3.1.6 | 765 | 6/10/2024 |
3.1.5 | 107 | 6/9/2024 |
3.1.4 | 650 | 5/30/2024 |
3.1.3 | 124 | 5/28/2024 |
3.1.2 | 115 | 5/27/2024 |
3.1.1 | 119 | 5/24/2024 |
3.0.7 | 121 | 5/24/2024 |
3.0.6 | 106 | 5/24/2024 |
3.0.5 | 128 | 5/20/2024 |
3.0.4 | 98 | 5/20/2024 |
3.0.3 | 145 | 5/6/2024 |
3.0.2 | 130 | 4/30/2024 |
3.0.1 | 140 | 4/29/2024 |
2.3.1 | 129 | 4/29/2024 |
2.2.18 | 117 | 4/22/2024 |
2.2.17 | 125 | 4/17/2024 |
2.2.16 | 121 | 4/16/2024 |
2.2.15 | 134 | 4/16/2024 |
2.2.14 | 132 | 4/15/2024 |
2.2.13 | 149 | 3/19/2024 |
2.2.12 | 136 | 3/11/2024 |
2.2.11 | 133 | 3/4/2024 |
2.2.10 | 147 | 2/26/2024 |
2.2.9 | 152 | 2/26/2024 |
2.2.8 | 132 | 2/25/2024 |
2.2.7 | 130 | 2/25/2024 |
2.2.6 | 137 | 2/25/2024 |
2.2.5 | 123 | 2/19/2024 |
2.2.4 | 121 | 2/19/2024 |
2.2.3 | 130 | 2/18/2024 |
2.2.2 | 131 | 2/18/2024 |
2.2.1 | 129 | 2/17/2024 |
2.1.3 | 125 | 2/14/2024 |
2.1.2 | 134 | 2/13/2024 |
2.1.1 | 127 | 2/13/2024 |
2.0.6 | 120 | 2/13/2024 |
2.0.5 | 157 | 2/12/2024 |
2.0.4 | 138 | 2/7/2024 |
2.0.3 | 123 | 2/7/2024 |
2.0.2 | 155 | 2/7/2024 |