Replace FAKE with Fun.Build.

[isaacabraham]

This (somewhat experimental) PR replaces FAKE with Fun.Build for the build project. The benefits of this PR are:

• Approximately 20% reduction in lock file (185 -> 150 LOC) - smaller lock file means quicker resolutions etc.
• Approximately 40% reduction in build project code (185 -> 105 LOC)
  • Part of this effort also includes simply removing some unnecessary symbols that were only used in one place, as well as simplifying each pipeline (think: FAKE target) to be more self contained.
  • Code is simpler, with no need for a Helpers file.
  • Code is easier to read and reason about.

I also have used this opportunity to only run a "clean" on doing a Bundle - there's no need to do it on a Run as far as I can see.

You can still run the "default" pipeline with a standard dotnet run. Running other pipelines uses dotnet run -- -p <pipeline name>.

We do lose the fancy colouration for Client and Server output, however,

[martinbryant]

• Like it for the reasons you have mentioned
• Are we considering it for the initial release or should we do it after?
• Is the running of other targets being different syntax an issue and/or can we consider looking at PR to library to make it work as it is currently?
• Work to be done to sort the template test by the looks of it
• What no colours?? ;) Again a PR or something to add this as with multiple targets I client/server/docker I find this really useful?

[mattgallagher92]

1. The code is much nicer (apart from the hideous "paralle" (sic.) keyword 😂) - what happens for each target is so much clearer.

2. Is the running of other targets being different syntax an issue and/or can we consider looking at PR to library to make it work as it is currently?

   @martinbryant you mean compared to FAKE? It's not a problem so long as it's clearly documented. The code comments make that clear, but updating the README would help too.

3. For me the colours aren't a dealbreaker, and I'd consider releasing the template without colours but, as you say, a PR to Fun.Build would make sense.

[mattgallagher92]

Reasons not to include this in SAFE v5.0.0 (but consider for v5.1.0):

• We know that FAKE extends well to other tools like Docker. I'd want to test drive Fun.Build a bit before including it in the template
• For feature parity, we probably should get console colours working
• There's more work to do and I don't think that it's worth delaying v5 much longer to get this in

Reasons to prefer FAKE anyway:

• FAKE is well established and battle tested
• FAKE has thorough docs
• FAKE has a large pool of contributors, so I have more confidence that it will be actively maintained for a long time yet

[isaacabraham]

@mattgallagher92 I agree - let's keep this PR going for post v5.0. FAKE - I'm unsure how many people are actively contributing to it nowadays TBH.

Remember that we can still use FAKE libraries - what we're essentially doing here is removing the FAKE target / composition bit and replacing with Fun.Build. As it turns out, we don't even need those FAKE libraries any longer - I just replaced the calls with standard .NET and it all works.

[isaacabraham]

@martinbryant I've fixed the test build now, this is now green.

[martinbryant]

Think we can look at closing #552 when completing this

[mattgallagher92]

@martinbryant we should first decide if we are going to adopt this approach or not (see #576 (comment)).

If we do merge these changes in, I think that you're probably right. We'd just be swapping one Build.fs file for one Build directory, which is not really more tidy. If we were to have more than one F# file for the build project, it'd be worth considering the approach suggested in #552 again.

[isaacabraham]

Is this generally accepted as "the way forward"? If so, I'll resolve the conflicts and get this ready on Friday.

[mattgallagher92]

I'm ambivalent. I don't feel any strong need to move away from FAKE, but the benefits you listed seem good. Moving back in future should be relatively easy if necessary.

Given that we're changing how programs like dotnet and npm are called, we should test on Windows, Mac and Linux before merging.

[mattgallagher92]

Resurrecting this discussion @isaacabraham.

I'm okay to switch, but I do think the lack of colouration might be pain for some users (us included). How nice would the code be if we wanted to share stages across multiple pipelines? E.g. docker compose up is a prerequisite for multiple operations we run in some codebases.

@jwthomson @Larocceau do you have any strong feelings?