Giraffe: Split NuGet packages

[dustinmoris]

I think it might make sense to:

• Move Giraffe.Razor into a separate repo under the org
• Move Giraffe.DotLiquid into a separate repo under the org
• Move giraffe-template into a separate repo under the org
• Extract Giraffe.TokenRouter into a separate repo, let it create its own NuGet package and make @gerardtoconnor an owner of that repo so that he can take the lead on that one and also doesn't have to wait for releasing quick bug features for me or someone else if urgent.

The first three points would be trivial, since all three projects already produce their own NuGet package. Only initial complication would be to remove the DotLiquid and Razor functionality from the sample apps and replicate the same demo in a new smaller sample app under the respective repo.

Any thoughts? /cc @JonCanning @TheAngryByrd

[forki]

I think TokenRouter should be promoted to the default and the other routing should be removed.

But we should definetly extract Giraffe.Tasks into own repo and make Giraffe depend on it. So we can use tasks everywhere in libs that don't need the full asp.net stack

[dustinmoris]

I think TokenRouter should be promoted to the default and the other routing should be removed.

I don't think that TokenRouter is a one bullet for all solution, see:

This implementation assumes that additional memory and compilation time is not an issue. If speed and performance of parsing and path matching is required then the Giraffe.TokenRouter is the preferred option.

Also not sure why the other routing must be immediately removed. I think the way it is now is perfect, because everyone get's what they want and there's the choice.

Can extract Giraffe.Tasks into separate NuGet package. We were also looking at migrating to TaskBuilder.fs, but didn't get this far yesterday. I see value though in keeping Giraffe.Tasks, but happy either way.

[forki]

no it's definetely not perfect, because we have type issues in both ways and this doubles the efforts. Also it puts burden on users to decide which one is better while the overhead is actually very little (AFAIK). We should be more opionated here, Also removing things early in alpha phase is much better than later when people adopted things

[gerardtoconnor]

This implementation assumes that additional memory and compilation time is not an issue

I wrote this in my code initially for scope and critical path but in practice the token router has tiny immaterial memory footprint and the compilation is in order of ms at start-up, both negligible.

I would like token router to be default at some stage as it is far more efficient and smart use of known data structures. Any missing functionality can be added if needed

[gerardtoconnor]

@forki is type inference still not working after beta300 on strings etc (putting %d issue aside)?

[forki]

I only tested it for tokenrouter and it seems to work.

Am 05.12.2017 12:45 schrieb "Gerard" [e-mail]:

@forki https://github.com/forki is type inference still not working
after beta300 on strings etc (putting %d issue aside)?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/giraffe-fsharp/Giraffe/issues/165#issuecomment-349280636,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNPTTyLhaUM4vpo1CpGbIQ0mnBIMxks5s9SzRgaJpZM4Q2Hlj
.

[dustinmoris]

I've moved Giraffe.Razor, Giraffe.DotLiquid and Giraffe.Tasks into their own repos and NuGet packages. I left Giraffe.TokenRouter in Giraffe with the outlook that it might become the default routing option at some point. I'll take a break now and will probably later tonight or tomorrow finish by moving the template into a separate repo, especially now where it has a dependency on Giraffe.Razor which is not inside the solution any more.