Consider moving build project to a build folder

[halcwb]

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 using npm start would be also be convenient.

[mattgallagher92]

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 run is more natural than npm start for 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 start would 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?

[halcwb]

@mattgallagher92
For a template recognizability is indeed very important. To just create a starting point using a build.cmd or build.sh would 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 build or dotnet test that's not working out of the box because then I have to specify the sln I want to use.

[mattgallagher92]

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 using dotnet 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 perform dotnet build and dotnet test respectively 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.

[mattgallagher92]

@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

[theprash]

@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 dotnet commands 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.

[isaacabraham]

Don't mind moving those files out of the root - it looks less complicated then too ;-) but we need to keep dotnet run.

[isaacabraham]

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.fs any longer I think).

[odytrice]

Personally, I just replace the build.fs with a build.fsx and perfer to take the hit with dotnet fsi build.fsx -t Run