Net5.0 & fable3

[theimowski]

No description provided.

[Zaid-Ajaj]

Fable.Remoting#201 - Fable.Remoting.Giraffe broken in Giraffe 5 is a blocker for this upgrade where latest Giraffe v5.0-pre that works with net5 isn't compatible with the Giraffe adapter from Fable.Remoting. It's a bit tricky on remoting side of things because upgrading the adapter also break backward-compat with applications using Giraffe [>= 3.6 && < 5]

[theimowski]

Thanks for the heads up. Until that issue is solved I'll pin Giraffe version to below v5

[theimowski]

@theprash do you think it's a good idea to move away from paket-based dependencies for fake build script and instead use the #r "nuget: Package" syntax? Wondering if that's the recommended way for fake scripts - can we guarantee pinned versions of resolved packages?

[Zaid-Ajaj]

Thanks for the heads up. Until that issue is solved I'll pin Giraffe version to below v5

@theimowski I just pushed a new version of Fable.Remoting.Giraffe v5.0.0-rc-6 that uses latest prerelease of Giraffe targeting net5. It should work in principle, let me know if you encounter any issues when using it

[isaacabraham]

@theimowski we've tried and it doesn't work for some reason that I don't fully understand (but Prash does). I think for now we've had to run our FAKE scripts via fsi or something.

[theprash]

@theimowski The main reason for moving was that FAKE seems to be tied to its own paket version which didn't support .NET 5. However, I never really liked the fake-cli approach, though I'm sure it has some advantages. One problem is that #r "paket: groupref build //" is a compile error everywhere except VS Code as far as I'm aware. And you need the additional
#load "./.fake/build.fsx/intellisense.fsx".

RE package resolution, no I don't think you can have completely reproducible package resolution with this method if NuGet doesn't provide it.

Another option is to run FAKE as a console project instead. I quite like this approach because you can easily use paket and you don't need any special tooling like fake-cli or any special #r commands that IDEs don't understand. You just dotnet run the console project. You can pass through the command line arguments and set up the FAKE environment in the same or similar way to what I already added to the top of build.fsx. It might be worth add a function to FAKE itself that can do this in one line.

[theimowski]

Yeah I think @Zaid-Ajaj also likes the idea of invoking FAKE via standard fsproj rather than fsx. I'll experiment with that approach.
The #r nuget syntax is great for quick setup and fire-and-forget scripts. However as it doesn't guarantee locked resolution, I'd rather not user it to run FAKE.

[theimowski]

Need to park updating to latest Giraffe prerelease, as Saturn needs to catch up SaturnFramework/Saturn#281

[theimowski]

af5bc09 is a PoC of using FAKE in fsproj rather than as fsx script

[theimowski]

Updated the PR to latest prerelease of Saturn and Giraffe - seems to work nice locally.
Would be curious to hear your thoughts on a different approach for running build as opposed to build.fsx - see updated README.md for default template.
Still need to fix the tests.

[theimowski]

Giraffe is now on stable v5.0, the only outstanding prerelease versions we depend in this PR are following (pinging maintainers to ask if we can expect a stable release soon?):

• Paket 6.0.0-rc001 @forki
• Saturn 0.15.0-preview03 @Krzysztof-Cieslak
• Fable.Remoting.Giraffe 5.7.0-rc-6 @Zaid-Ajaj

[isaacabraham]

@theimowski there's another blocker we've noticed recently which is related to Fable Remoting (we think) that's causing issues on Azure - it's forcing you to run in 64 bit mode which isn't available on the free tier, which I really want to keep.

[isaacabraham]

@theimowski I think removing Babel is fine as long as we have a recipe for adding support for IE

[kerams]

Fable.Remoting.Giraffe 5.7.0-rc-6

v5 of this package is in lockstep with Giraffe itself, so now that the latter is stable, there's no technical reason that I know of why Fable.Remoting.Giraffe should not follow suit.

@isaacabraham, how do you figure? By process of elimination? Please open an issue if you know more.

[isaacabraham]

@kerams there's already some open issue on Fable.Remoting (I think!) - I think it's related to another library though - one by Eirik Tsarpalis (though I can't remember the name). @Akash-Mair can you let us know where that issue is / was?

[kerams]

It's Zaid-Ajaj/Fable.Remoting#226, but I took it that the problem had been resolved. The new report is based on the current stable version of the template, right? If that's the case, I believe it could be referring to an old version of Remoting without the fix , so we should (hopefully) be good here. On second thought, the version isn't pinned in paket.dependencies.

[Zaid-Ajaj]

@theimowski A stable package of Fable.Remoting.Giraffe v5.0 has been published that depends on Giraffe v5.0

There were also bug fixes to Fable.Remoting.Client which can also be updated to latest v7.12.0 (char type serialization / ignoring connectivity errors when status code = 0 of HTTP requests)

[isaacabraham]

@theimowski @Zaid-Ajaj there's a PR open that upgrades all deps to latest.

[isaacabraham]

Wow. I think we're good to do - there's a conflict on the project-local json that I think can be overwritten by what's in this branch?

[FredericEspiau]

Wow. I think we're good to do - there's a conflict on the project-local json that I think can be overwritten by what's in this branch?

https://github.com/SAFE-Stack/SAFE-template/blob/master/Content/minimal/package.json

Makes sense yes, the conflict shouldn't matter much and the latest changes by Dependabot are already taken into account:

• Bump elliptic from 6.5.3 to 6.5.4 in /Content/minimal #433

Dependabot latest PR

• SAFE-template/Content/minimal/package-lock.json

  Line 10026 in 1b28e1e

  "elliptic": {

elliptic is already at version 6.5.4 in the current PR

[theimowski]

Yeah the conflict can probably be even resolved locally if necessary - just force merge using this branch changes as it diverged quite significantly from master anyway.
I'm happy to roll out stable v3 release as soon as we agree docs are ready too 👍

[isaacabraham]

@theimowski right, everything looks ready. let's do it!

[comintel]

Beta 4 works for me, but beta 5 and 3.0.0 give this error:

PS D:\data-vs-code-workspaces\SAFEDir> dotnet new SAFE --force
Template "SAFE-Stack Web App v3.0.0" could not be created.
Error while processing file /Content/default/node_modules.orig/nan/nan.h
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index')
at System.Collections.Generic.List1.get_Item(Int32 index) at Microsoft.TemplateEngine.Core.Expressions.Cpp.CppStyleEvaluatorDefinition.Evaluate(IProcessorState processor, Int32& bufferLength, Int32& currentBufferPosition, Boolean& faulted) at Microsoft.TemplateEngine.Core.Operations.Conditional.Impl.HandleMatch(IProcessorState processor, Int32 bufferLength, Int32& currentBufferPosition, Int32 token, Stream target) at Microsoft.TemplateEngine.Core.Util.ProcessorState.Run() at Microsoft.TemplateEngine.Core.Util.Processor.Run(Stream source, Stream target, Int32 bufferSize, Int32 flushThreshold) at Microsoft.TemplateEngine.Core.Util.Processor.Run(Stream source, Stream target, Int32 bufferSize) at Microsoft.TemplateEngine.Core.Util.Processor.Run(Stream source, Stream target) at Microsoft.TemplateEngine.Core.Util.Orchestrator.ProcessFile(IFile sourceFile, String sourceRel, String targetDir, IGlobalRunSpec spec, IProcessor fallback, IEnumerable1 fileGlobProcessors, IReadOnlyList`1 locOperations)

[davidhayesbc]

I see the same issue as comintel

[theimowski]

My bad - for some reason I had a dirty directory locally that got packaged into the nupkg. Should be solved now with 3.0.1

[davidhayesbc]

Thanks, that fixed it for me! Looking forward to getting started on my F# web journey

[comintel]

Working perfectly now for me also, THANK YOU