NotAShelf/nvf
2
1
Fork 0
mirror of https://github.com/NotAShelf/nvf.git synced 2025-09-06 18:31:35 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 3

docs: format via deno fmt

Browse source 
This should be a pre-commit hook in the future.
This commit is contained in:
raf 2024-11-25 19:16:46 +03:00
commit a196e9610f
Signed by: NotAShelf
GPG key ID: AF26552424E53993
11 changed files with 114 additions and 117 deletions
Download patch file Download diff file Expand all files Collapse all files

89
docs/manual/hacking/guidelines.md
View file

@ -3,30 +3,29 @@
If your contribution tightly follows the guidelines, then there is a good chance
it will be merged without too much trouble. Some of the guidelines will be
strictly enforced, others will remain as gentle nudges towards the correct
direction. As we have no automated system enforcing those guidelines, please
try to double check your changes before making your pull request in order to
avoid "faulty" code slipping by.
direction. As we have no automated system enforcing those guidelines, please try
to double check your changes before making your pull request in order to avoid
"faulty" code slipping by.
If you are uncertain how these rules affect the change you would like to make
then feel free to start a discussion in the [discussions tab](https://github.com/NotAShelf/nvf/discussions)
ideally (but not necessarily) before you start developing.
then feel free to start a discussion in the
[discussions tab](https://github.com/NotAShelf/nvf/discussions) ideally (but not
necessarily) before you start developing.
## Adding Documentation {#sec-guidelines-documentation}
Most, if not all, changes warrant changes to the documentation. Module options
should be documented with [Nixpkgs-flavoured Markdown](https://nixos.org/manual/nixpkgs/unstable/#sec-contributing-markup),
should be documented with
[Nixpkgs-flavoured Markdown](https://nixos.org/manual/nixpkgs/unstable/#sec-contributing-markup),
albeit with exceptions.
::: {.note}
As of **v0.5**, **nvf** is itself documented using full markdown in both module
options and the manual. With **v0.6**, this manual has also been converted to
markdown in full.
:::
::: {.note} As of **v0.5**, **nvf** is itself documented using full markdown in
both module options and the manual. With **v0.6**, this manual has also been
converted to markdown in full. :::
The HTML version of this manual containing both the module option descriptions
and the documentation of **nvf** (such as this page) can be generated and
opened by typing the following in a shell within a clone of the **nvf** Git
repository:
and the documentation of **nvf** (such as this page) can be generated and opened
by typing the following in a shell within a clone of the **nvf** Git repository:
```console
$ nix build .#docs-html
@ -35,28 +34,28 @@ $ xdg-open $PWD/result/share/doc/nvf/index.html
## Formatting Code {#sec-guidelines-formatting}
Make sure your code is formatted as described in [code-style
section](#sec-guidelines-code-style). To maintain consistency throughout the
project you are encouraged to browse through existing code and adopt its style
also in new code.
Make sure your code is formatted as described in
[code-style section](#sec-guidelines-code-style). To maintain consistency
throughout the project you are encouraged to browse through existing code and
adopt its style also in new code.
## Formatting Commits {#sec-guidelines-commit-message-style}
Similar to [code style guidelines](#sec-guidelines-code-style) we encourage a
consistent commit message format as described in [commit style
guidelines](#sec-guidelines-commit-style).
consistent commit message format as described in
[commit style guidelines](#sec-guidelines-commit-style).
## Commit Style {#sec-guidelines-commit-style}
The commits in your pull request should be reasonably self-contained. Which
means each and every commit in a pull request should make sense both on its
own and in general context. That is, a second commit should not resolve an
issue that is introduced in an earlier commit. In particular, you will be
asked to amend any commit that introduces syntax errors or similar problems
even if they are fixed in a later commit.
means each and every commit in a pull request should make sense both on its own
and in general context. That is, a second commit should not resolve an issue
that is introduced in an earlier commit. In particular, you will be asked to
amend any commit that introduces syntax errors or similar problems even if they
are fixed in a later commit.
The commit messages should follow the [seven
rules](https://chris.beams.io/posts/git-commit/#seven-rule), except for
The commit messages should follow the
[seven rules](https://chris.beams.io/posts/git-commit/#seven-rule), except for
"Capitalize the subject line". We also ask you to include the affected code
component or module in the first line. A commit message ideally, but not
necessarily, follow the given template from home-manager's own documentation
@ -69,15 +68,16 @@ necessarily, follow the given template from home-manager's own documentation
where `{component}` refers to the code component (or module) your change
affects, `{description}` is a very brief description of your change, and
`{long description}` is an optional clarifying description. As a rare
exception, if there is no clear component, or your change affects many
components, then the `{component}` part is optional. See [example commit
message](#sec-guidelines-ex-commit-message) for a commit message that
fulfills these requirements.
`{long description}` is an optional clarifying description. As a rare exception,
if there is no clear component, or your change affects many components, then the
`{component}` part is optional. See
[example commit message](#sec-guidelines-ex-commit-message) for a commit message
that fulfills these requirements.
## Example Commit {#sec-guidelines-ex-commit-message}
The commit [69f8e47e9e74c8d3d060ca22e18246b7f7d988ef](https://github.com/nix-community/home-manager/commit/69f8e47e9e74c8d3d060ca22e18246b7f7d988ef)
The commit
[69f8e47e9e74c8d3d060ca22e18246b7f7d988ef](https://github.com/nix-community/home-manager/commit/69f8e47e9e74c8d3d060ca22e18246b7f7d988ef)
in home-manager contains the following commit message.
```
@ -112,21 +112,22 @@ to contain the parent as well - for example `languages/java: some major change`.
### Treewide {#sec-code-style-treewide}
Keep lines at a reasonable width, ideally 80 characters or less. This also applies
to string literals and module descriptions and documentation.
Keep lines at a reasonable width, ideally 80 characters or less. This also
applies to string literals and module descriptions and documentation.
### Nix {#sec-code-style-nix}
**nvf** is formatted by the [alejandra](https://github.com/kamadorueda/alejandra)
tool and the formatting is checked in the pull request and push workflows. Run the
`nix fmt` command inside the project repository before submitting your pull request.
**nvf** is formatted by the
[alejandra](https://github.com/kamadorueda/alejandra) tool and the formatting is
checked in the pull request and push workflows. Run the `nix fmt` command inside
the project repository before submitting your pull request.
While Alejandra is mostly opinionated on how code looks after formatting,
certain changes are done at the user's discretion based on how the original
code was structured.
certain changes are done at the user's discretion based on how the original code
was structured.
Please use one line code for attribute sets that contain only one subset.
For example:
Please use one line code for attribute sets that contain only one subset. For
example:
```nix
# parent modules should always be unfolded
@ -158,8 +159,8 @@ module = {
```
For lists, it is mostly up to your own discretion how you want to format them,
but please try to unfold lists if they contain multiple items and especially
if they are to include comments.
but please try to unfold lists if they contain multiple items and especially if
they are to include comments.
```nix
# this is ok