Repository navigation
Consider moving build project to a build folder #552
Description
Activity
Thanks for the suggestion @halcwb! I agree that it's a little untidy to have the build project's files right at the repo root.
My opinion is that
dotnet runis more natural thannpm startfor a few reasons:- The build project is actually defined in .NET.
- The code is compiled using dotnet tools, hence dotnet feels more integral to the stack.
npm startwould mean one more layer of indirection, which might be confusing to newcomers. There's already a lot to take in if you're only familiar with one of the .NET or JavaScript ecosystems.- Ultimately, the application will be running in a .NET environment.
However, I don't feel particularly strongly about any of those points.
A compromise approach could be to leave Build.fsproj where it is, but move Build.fs and Helpers.fs into a subdirectory (for example
./build/or./src/build/). What do you think?@mattgallagher92
For a template recognizability is indeed very important. To just create a starting point using abuild.cmdorbuild.shwould also work I think. But this is more a subjective taste issue?With the current setup the problem I have is when I do a
dotnet buildordotnet testthat's not working out of the box because then I have to specify theslnI want to use.At Compositional IT, we'd usually approach that by having dedicated build targets in the build project. There is already a
"RunTests"build target in the template, executable usingdotnet run RunTests:SAFE-template/Content/default/Build.fs
Lines 55 to 60 in 91c1672
Target.create "RunTests" (fun _ -> run dotnet "build" sharedTestsPath [ "server", dotnet "watch run" serverTestsPath "client", dotnet "fable watch -o output -s --run npm run test:live" clientTestsPath ] |> runParallel ) You could create your own targets, for example
"BuildSln"and"TestSln"that performdotnet buildanddotnet testrespectively against the solution.That way the build project always behaves as the target of your
dotnet run ...commands, and is always the command-line entry point into actions against your codebase. Build.fs then captures the actual behaviour of those commands somewhat analogously to how build.cmd or build.sh would.Reacted by Casper and Rico Saupe@isaacabraham @theprash I'd be interested in your thoughts regarding this:
leave Build.fsproj where it is, but move Build.fs and Helpers.fs into a subdirectory
@mattgallagher92 I like the idea of moving those files out of the root.
And I agree that normally everything is done through FAKE targets in the build project rather than plain
dotnetcommands at the root dir so making the build project easy to call is the priority. It's not ideal to have it running through npm as that's yet another layer as you mentioned, and also a change to all of the existing docs and expectations for not a huge benefit.Don't mind moving those files out of the root - it looks less complicated then too ;-) but we need to keep
dotnet run.If we include #576 then I'm not sure it's worth having a folder for a single file though (we won't need
Helpers.fsany longer I think).- changed the title
[-]Consider moving build sln to a build folder[/-][+]Consider moving build project to a build folder[/+]on Jan 25, 2024 Personally, I just replace the build.fs with a build.fsx and perfer to take the hit with
dotnet fsi build.fsx -t RunReacted by Isaac Abraham
Currently, the build project sits right at the root folder of the template. Wouldn't it be better to move this to a 'build' folder instead? Only, then you can't just
dotnet run, but fixing this in the package.json and usingnpm startwould be also be convenient.