I've created a [GitHub repository template](https://help.github.com/en/articles/creating-a-repository-from-a-template) for Nim projects:
* [https://github.com/tajmone/nim-repository-template](https://github.com/tajmone/nim-repository-template) * [https://github.com/tajmone/nim-repository-template/wiki](https://github.com/tajmone/nim-repository-template/wiki) The idea is to provide a boilerplate for quickly creating new Nim projects with all the basic settings in place for any cross-platform project. This should be particularly helpful for Nim newbies (like me) who might not know all the Nim related file extensions that could show up in a project. For example, I've also added some GitHub Linguist attributes to indicate that `*.nimf` files should be considered Nim files in project statistic and syntax highlighting (the new SFF extension has not yet been added to Linguist). The template is far for complete, just an initial proposal. >From an exchange with @Araq, I learned that the best practice is to always set >Git to normalize EOLs to LF, even under Windows OS: * [https://github.com/nim-lang/c2nim/issues/171](https://github.com/nim-lang/c2nim/issues/171) Many editors packages for Nim use native EOL for Nim sources, and I haven't find any references in the official documentation regarding best practices for these type of settings in commonly shared projects. So I was hoping that this repository might be useful in this respect — it's Wiki is open to editing and can be used to provide guidelines. My original idea was to create the repository and then transfer ownership to the Nim-Lang GitHub organization, but then I realized you can only transfer repositories to organizations where you have enough privileges to create repositories yourself (I though I could simply request transferal, and the Nim-Lang org could accept or decline). Repository templates are a new GitHub features (June 2019) which I think is quite cool. Beside saving time when creating new repositories, the presets of a well designed template can also cover a variety of work scenarios, different compiler backends, etc.
