Skip to content

Consider moving build project to a build folder #552

Description

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

Activity

  1. mattgallagher92 commented on Mar 17, 2023

    @mattgallagher92
    Collaborator

    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?

  2. halcwb commented on Mar 18, 2023

    @halcwb
    Author

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

  3. mattgallagher92 commented on Mar 23, 2023

    @mattgallagher92
    Collaborator

    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:

    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.

  4. mattgallagher92 commented on Mar 31, 2023

    @mattgallagher92
    Collaborator

    @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

  5. theprash commented on Mar 31, 2023

    @theprash
    Member

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

  6. isaacabraham commented on Jan 5, 2024

    @isaacabraham
    Member

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

  7. isaacabraham commented on Jan 23, 2024

    @isaacabraham
    Member

    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).

  8. changed the title [-]Consider moving build sln to a build folder[/-] [+]Consider moving build project to a build folder[/+] on Jan 25, 2024
  9. odytrice commented on Feb 25, 2024

    @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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions