- Add links to GH project in all places marked
https://github.com/kMutagene/FSharpColors
- Add name of the author in all places marked
Kevin Schneider
- Search for any other places marked with
TODO:
(especially inbuild.fsx
script)
- Paket, FAKE, and Fornax added as
dotnet
local tools (.config/dotnet-tools.json
) build.fsx
file, containing default FAKE script with targets for building, testing, documentation generation, publishing to GitHub, and publishing to NuGetpaket.dependencies
with basic set of dependenciessrc
folder containing 2 projects - one class library (netstandard2.0
), and CLI tool (netcoreapp3.1
)test
folder containing UnitTest project using Expecto and FsCheckdocs
folder with Fornax documentation template that will generate nice documentation for your project..devcontainer
folder with definition of Development Container.github/workflows
folder with definition for 3 GitHub actions - one for building and testing code as CI, one for creating new GH releases on new tags, one for deploying documentation when new tag is pushed. To use latter, you need to definePERSONAL_TOKEN
secret in GitHub repo settings with Personal Access Token..github/ISSUE_TEMPLATE
folder with 2 different issue templates - one for bug report, other one for feature request
- Make sure you've installed .Net Core version defined in global.json
- Run
dotnet tool restore
to install all developer tools required to build the project - Run
dotnet fake build
to build default target of build script - To run tests use
dotnet fake build -t Test
- To build documentation use
dotnet fake build -t Docs
- Make sure you've installed .Net Core version defined in global.json
- Run
dotnet tool restore
to install all developer tools required to build the project - Run
dotnet fake build
to build default target of build script - Build documentation to make sure everything is fine with
dotnet fake build -t Docs
- Go to docs folder
cd docs
and start Fornax in watch modedotnet fornax watch
- You documentation should be now accessible on
localhost:8080
and will be regenerated on every file save
- Update CHANGELOG.md by adding new entry (
## [X.Y.Z]
) and commit it. - Create version tag (
git tag vX.Y.Z
) - Run
dotnet fake build -t Pack
to create the nuget package and test/examine it locally. - Push the tag to the repo
git push origin vX.Y.Z
- this will start CI process that will create GitHub release and put generated NuGet packages in it - Upload generated packages into NuGet.org
In case you don't want to create releases automatically as part of the CI process, we provide also set of helper targets in build.fsx
script.
Create release.cmd or release.sh file (already git-ignored) with following content (sample from cmd
, but sh
file should be similar):
@echo off
cls
SET nuget-key=YOUR_NUGET_KEY
SET github-user=YOUR_GH_USERNAME
SET github-pw=YOUR_GH_PASSWORD_OR_ACCESS_TOKEN
dotnet fake build --target Release
Template includes, out-of-the-box, nice theme for your project documentation, which integrates with FSharp.Formatting to create also API reference
- Sample documentation produced by the template can be found on http://kcieslak.io/SampleFSharpColors.
- Created theme is partial port to Fornax of Hugo Learn theme.
- You define content as markdown files
- Menu navigation based on the documentation system described on https://documentation.divio.com/
- Use FSharp.Formatting to create API reference for the project - sample: http://kcieslak.io/SampleFSharpColors/Reference/ApiRef.html
- Use Lunr.js to provide client side search based on generated by Fornax search index - sample: try searching for
Lorem
orSample
in search available on http://kcieslak.io/SampleFSharpColors - Use Mermaid.js to provide client side render diagrams and graphs - sample: http://kcieslak.io/SampleFSharpColors/diagrams.html
Imposter syndrome disclaimer: I want your help. No really, I do.
There might be a little voice inside that tells you you're not ready; that you need to do one more tutorial, or learn another framework, or write a few more blog posts before you can help me with this project.
I assure you, that's not the case.
This project has some clear Contribution Guidelines and expectations that you can read here.
The contribution guidelines outline the process that you'll need to follow to get a patch merged. By making expectations and process explicit, I hope it will make it easier for you to contribute.
And you don't just have to write code. You can help out by writing documentation, tests, or even by giving feedback about this work. (And yes, that includes giving feedback about the contribution guidelines.)
Thank you for contributing!
The project is hosted on GitHub where you can report issues, fork the project and submit pull requests.
The library is available under MIT license, which allows modification and redistribution for both commercial and non-commercial purposes.
Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.