Open halcwb opened 1 year ago
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:
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.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 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.
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
: https://github.com/SAFE-Stack/SAFE-template/blob/91c167293cddc63f474caf911907fefa245f3bba/Content/default/Build.fs#L55-L60
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.
@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 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.
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.fs
any longer I think).
Personally, I just replace the build.fs with a build.fsx and perfer to take the hit with dotnet fsi build.fsx -t Run
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 start
would be also be convenient.