search

AngelMunoz / SafePerla

A SAFE stack template that uses Perla for the frontend rather than webpack/vite
6 stars 0 forks source link

System.IO.DirectoryNotFoundException on first dotnet run #1

Open theimowski opened 2 years ago

theimowski commented 2 years ago

Hi @AngelMunoz I've been brought here from https://github.com/SAFE-Stack/SAFE-template/issues/532 and wanted to give Perla a shot. For some reason when I do dotnet run on a fresh repository, following exception is thrown:

...
server: /Users/theimowski/oss/AngelMunoz/SafePerla/src/Server> dotnet watch run
client: /Users/theimowski/oss/AngelMunoz/SafePerla/src/Client> dotnet perla serve
/Users/theimowski/oss/AngelMunoz/SafePerla/src/Server> "dotnet" watch run (In: false, Out: true, Err: true)
/Users/theimowski/oss/AngelMunoz/SafePerla/src/Client> "dotnet" perla serve (In: false, Out: true, Err: true)
client: Perla: Checking whether esbuild is present...
client: Perla: esbuild is present.
client: Perla:Serve: Starting Dev Server
client: Perla:Serve: Starting Fable
client: Unhandled exception. System.IO.DirectoryNotFoundException: /Users/theimowski/oss/AngelMunoz/SafePerla/src/Client/output/
client:    at Microsoft.Extensions.FileProviders.PhysicalFileProvider..ctor(String root, ExclusionFilters filters)
client:    at Perla.Lib.Server.devServer(PerlaConfig config) in /Users/tuna/repos/Perla/src/Perla.Lib/Server.fs:line 656
client:    at Perla.Lib.Server.startServer(PerlaConfig config) in /Users/tuna/repos/Perla/src/Perla.Lib/Server.fs:line 706
client:    at Perla.Lib.Server.serverActions@724-1.Invoke(Unit unitVar) in /Users/tuna/repos/Perla/src/Perla.Lib/Server.fs:line 725
client:    at Microsoft.FSharp.Control.AsyncPrimitives.CallThenInvoke[T,TResult](AsyncActivation`1 ctxt, TResult result1, FSharpFunc`2 part2) in D:\a\_work\1\s\src\FSharp.Core\async.fs:line 508
client:    at Microsoft.FSharp.Control.Trampoline.Execute(FSharpFunc`2 firstAction) in D:\a\_work\1\s\src\FSharp.Core\async.fs:line 112
client: --- End of stack trace from previous location ---
client:    at Microsoft.FSharp.Control.AsyncPrimitives.Start@1167-1.Invoke(ExceptionDispatchInfo edi) in D:\a\_work\1\s\src\FSharp.Core\async.fs:line 1167
client:    at Microsoft.FSharp.Control.Trampoline.Execute(FSharpFunc`2 firstAction) in D:\a\_work\1\s\src\FSharp.Core\async.fs:line 112
client:    at <StartupCode$FSharp-Core>.$Async.clo@193-15.Invoke(Object o) in D:\a\_work\1\s\src\FSharp.Core\async.fs:line 195
client:    at System.Threading.QueueUserWorkItemCallbackDefaultContext.Execute()
client:    at System.Threading.ThreadPoolWorkQueue.Dispatch()
client:    at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
client:    at System.Threading.Thread.StartCallback()
server: dotnet watch 🚀 Started
...

interestingly, after I cancel the run, the directory is there and subsequent dotnet run works fine - smells like some kind of race condition possibly? I'm using MacOS FWIW

AngelMunoz commented 2 years ago

Interesting, yes it may be, specially because of the mounted directory (src/Client/output) is created only after fable produces it's sources, the asp net server that backs perla is way faster than that

I guess we need to check (and create if necessary) the mounted directories if they don't exist so the file provider doesn't die there