doc: port existing content
Signed-off-by: Brian McGee <brian@bmcgee.ie>
This commit is contained in:
parent
b86d0f897f
commit
73722737f6
GPG Key ID:
D49016E76AD1E8C0
|
|
@ -11,17 +11,16 @@ export default defineConfig({
|
|||
// https://vitepress.dev/reference/default-theme-config
|
||||
nav: [
|
||||
{ text: 'Home', link: '/' },
|
||||
{ text: 'Examples', link: '/markdown-examples' }
|
||||
{ text: 'Quick Start', link: '/quick-start' }
|
||||
],
|
||||
|
||||
sidebar: [
|
||||
{
|
||||
text: 'Examples',
|
||||
items: [
|
||||
{ text: 'Markdown Examples', link: '/markdown-examples' },
|
||||
{ text: 'Runtime API Examples', link: '/api-examples' }
|
||||
]
|
||||
}
|
||||
{ text: 'Quick Start', link: '/quick-start' },
|
||||
{ text: 'Overview', link: '/overview' },
|
||||
{ text: 'Usage', link: '/usage' },
|
||||
{ text: 'Formatter Spec', link: '/formatter-spec' },
|
||||
{ text: 'Contributing', link: '/contributing' },
|
||||
{ text: 'FAQ', link: '/faq' },
|
||||
],
|
||||
|
||||
socialLinks: [
|
||||
|
|
|
|||
|
|
@ -1,55 +0,0 @@
|
|||
---
|
||||
outline: deep
|
||||
---
|
||||
|
||||
# Runtime API Examples
|
||||
|
||||
This page demonstrates usage of some of the runtime APIs provided by VitePress.
|
||||
|
||||
The main `useData()` API can be used to access site, theme, and page data for the current page. It works in both `.md` and `.vue` files:
|
||||
|
||||
```md
|
||||
<script setup>
|
||||
import { useData } from 'vitepress'
|
||||
|
||||
const { theme, page, frontmatter } = useData()
|
||||
</script>
|
||||
|
||||
## Results
|
||||
|
||||
### Theme Data
|
||||
|
||||
<pre>{{ theme }}</pre>
|
||||
|
||||
### Page Data
|
||||
|
||||
<pre>{{ page }}</pre>
|
||||
|
||||
### Page Frontmatter
|
||||
|
||||
<pre>{{ frontmatter }}</pre>
|
||||
```
|
||||
|
||||
<script setup>
|
||||
import { useData } from 'vitepress'
|
||||
|
||||
const { site, theme, page, frontmatter } = useData()
|
||||
</script>
|
||||
|
||||
## Results
|
||||
|
||||
### Theme Data
|
||||
|
||||
<pre>{{ theme }}</pre>
|
||||
|
||||
### Page Data
|
||||
|
||||
<pre>{{ page }}</pre>
|
||||
|
||||
### Page Frontmatter
|
||||
|
||||
<pre>{{ frontmatter }}</pre>
|
||||
|
||||
## More
|
||||
|
||||
Check out the documentation for the [full list of runtime APIs](https://vitepress.dev/reference/runtime-api#usedata).
|
||||
145
docs/contributing.md
Normal file
145
docs/contributing.md
Normal file
|
|
@ -0,0 +1,145 @@
|
|||
---
|
||||
outline: deep
|
||||
---
|
||||
|
||||
# Contribution guidelines
|
||||
|
||||
This file contains instructions that will help you make a contribution.
|
||||
|
||||
## Licensing
|
||||
|
||||
The treefmt binaries and this user guide are licensed under the [MIT license](https://numtide.github.io/treefmt/LICENSE.html).
|
||||
|
||||
## Before you contribute
|
||||
|
||||
Here you can take a look at the [existing issues](https://github.com/numtide/treefmt/issues). Feel free to contribute, but make sure you have a [GitHub account](https://github.com/join) first :) .
|
||||
|
||||
If you're new to open source, please read GitHub's guide on [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/). It's a quick read, and it's a great way to introduce yourself to how things work behind the scenes in open-source projects.
|
||||
|
||||
Before sending a pull request, make sure that you've read all the guidelines. If you don't understand something, please [state your question clearly in an issue](https://github.com/numtide/treefmt/issues/new) or ask the community on the [treefmt matrix server](https://matrix.to/#/#treefmt:numtide.com).
|
||||
|
||||
## Creating an issue
|
||||
|
||||
If you need to create an issue, make sure to clearly describe it, including:
|
||||
|
||||
- The steps to reproduce it if it's a bug
|
||||
- The version of treefmt used
|
||||
- The database driver and version
|
||||
- The database version
|
||||
|
||||
The cache database is stored in a toml file the ~/.cache/treefmt directory.
|
||||
|
||||
## Making changes
|
||||
|
||||
If you want to introduce changes to the project, please follow these steps:
|
||||
|
||||
- Fork the repository on GitHub
|
||||
- Create a branch on your fork. Don't commit directly to main
|
||||
- Add the necessary tests for your changes
|
||||
- Run treefmt in the source directory before you commit your changes
|
||||
- Push your changes to the branch in your repository fork
|
||||
- Submit a pull request to the original repository
|
||||
|
||||
Make sure you based your commits on logical and atomic units!
|
||||
|
||||
## Examples of git history
|
||||
|
||||
Git history that we want to have:
|
||||
|
||||
Git history that we are trying to avoid:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Git history that we want to have</summary>
|
||||
|
||||
```
|
||||
|
||||
* e3ed88b (HEAD -> contribution-guide, upstream/main, origin/main, origin/HEAD, main) Merge pull request #470 from zimbatm/fix_lru_cache
|
||||
|
||||
|\
|
||||
|
||||
| * 1ab7d9f Use rayon for multithreading command
|
||||
|
||||
|/
|
||||
|
||||
* e9c5bb4 Merge pull request #468 from zimbatm/multithread
|
||||
|
||||
|\
|
||||
|
||||
| * de2d6cf Add lint property for Formatter struct
|
||||
|
||||
| * cd2ed17 Fix impl on Formatter get_command() function
|
||||
|
||||
|/
|
||||
|
||||
* 028c344 Merge pull request #465 from rayon/0.15.0-release
|
||||
|
||||
|\
|
||||
|
||||
| * 7b619d6 0.15.0 release
|
||||
|
||||
|/
|
||||
|
||||
* acdf7df Merge pull request #463 from zimbatm/support-multi-part-namespaces
|
||||
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Git history that we are <b>trying</b> to avoid:</summary>
|
||||
|
||||
```
|
||||
|
||||
* 4c8aca8 Merge pull request #120 from zimbatm/add-rayon
|
||||
|
||||
|\
|
||||
|
||||
| * fc2b449 use rayon for engine now
|
||||
|
||||
| * 2304683 add rayon config
|
||||
|
||||
| * 5285bd3 bump base image to F30
|
||||
|
||||
* | 4d0fbe2 Merge pull request #114 from rizary/create_method_create_release
|
||||
|
||||
|\ \
|
||||
|
||||
| * | 36a9396 test changed
|
||||
|
||||
| * | 22f681d method create release for github created
|
||||
|
||||
* | | 2ef4ea1 Merge pull request #119 from rizary/config.rs
|
||||
|
||||
|\ \ \
|
||||
|
||||
| |/ /
|
||||
|
||||
|/| |
|
||||
|
||||
| * | 5f1b8f0 unused functions removed
|
||||
|
||||
* | | a93c361 Merge pull request #117 from zimbatm/add-getreleases-to-abstract
|
||||
|
||||
|\ \ \
|
||||
|
||||
| |/ /
|
||||
|
||||
|/| |
|
||||
|
||||
| * | 0a97236 add get_releses for Cargo
|
||||
|
||||
| * | 55e4c57 add get_releases/get_release into engine.rs
|
||||
|
||||
|/ /
|
||||
|
||||
* | badeddd Merge pull request #101 from zimbatm/extreme-cachin
|
||||
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
Additionally, it's always good to work on improving documentation and adding examples.
|
||||
|
||||
Thank you for considering contributing to `treefmt`.
|
||||
19
docs/faq.md
Normal file
19
docs/faq.md
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
# FAQ
|
||||
|
||||
## How does treefmt function?
|
||||
|
||||
`Treefmt` traverses all your project's folders, maps files to specific code formatters, and formats the code accordingly. Other tools also traverse the filesystem, but not necessarily starting from the root of the project.
|
||||
|
||||
Contrary to other formatters, `treefmt` doesn't preview the changes before writing them to a file. If you want to view the changes, you can always check the diff in your version control (we assume that your project is checked into a version control system). You can also rely on version control if errors were introduced into your code as a result of disruptions in the formatter's work.
|
||||
|
||||
## How is the cache organized?
|
||||
|
||||
At this moment, the cache is represented by a flat TOML file where file paths are mapped to `mtimes`. The file is located in:
|
||||
|
||||
```
|
||||
~/.cache/treefmt/<hash-of-the-treefmt.toml-path>.toml
|
||||
```
|
||||
|
||||
However, we are planning to move the hash file to the destination project's root directory.
|
||||
|
||||
At the end of each tool run, the cache file gets overwritten with the last formatting time entries. In this way, we can can compare the last change time of the file to the last formatting time, and figure out which files need re-formatting.
|
||||
55
docs/formatter-spec.md
Normal file
55
docs/formatter-spec.md
Normal file
|
|
@ -0,0 +1,55 @@
|
|||
---
|
||||
outline: deep
|
||||
---
|
||||
|
||||
# Formatter Specification
|
||||
|
||||
In order to keep the design of `treefmt` simple, we support only formatters which adhere to a certain standard. This document outlines this standard. If the formatter you would like to use doesn't comply with the rules, it's often possible to create a wrapper script that transforms the usage to match the specification.
|
||||
|
||||
In this design, we rely on `treefmt` to do the tree traversal, and only invoke
|
||||
the code formatter on the selected files.
|
||||
|
||||
## Rules
|
||||
|
||||
In order for the formatter to comply to this spec, it MUST follow the
|
||||
following rules:
|
||||
|
||||
### 1. Files passed as arguments
|
||||
|
||||
In order to be integrated to `treefmt`'s workflow, the formatter's CLI must adhere to the following specification:
|
||||
|
||||
```
|
||||
<command> [options] [...<files>]
|
||||
```
|
||||
|
||||
Where:
|
||||
|
||||
- `<command>` is the name of the formatting tool.
|
||||
- `[options]` is any number of flags and options that the formatter accepts.
|
||||
- `[...<files>]` is one or more files given to the formatter for processing.
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
$ rustfmt --edition 2018 src/main.rs src/lib.rs
|
||||
```
|
||||
|
||||
It SHOULD processes only the specified files. Files that are not passed SHOULD never be formatted.
|
||||
|
||||
### 2. Write to changed files
|
||||
|
||||
Whenever there is a change to the code formatting, the code formatter MUST
|
||||
write to the changes back to the original location.
|
||||
|
||||
If there is no changes to the original file, the formatter MUST NOT write to
|
||||
the original location.
|
||||
|
||||
### 3. Idempotent
|
||||
|
||||
The code formatter SHOULD be indempotent. Meaning that it produces stable
|
||||
outputs.
|
||||
|
||||
### 4. Reliable
|
||||
|
||||
We expect the formatter to be reliable and not break the semantic of the
|
||||
formatted files.
|
||||
143
docs/formatters.md
Normal file
143
docs/formatters.md
Normal file
|
|
@ -0,0 +1,143 @@
|
|||
# A list of known formatters
|
||||
|
||||
Here is a list of all the formatters we tested. Feel free to send a PR to add
|
||||
other ones!
|
||||
|
||||
## [prettier](https://prettier.io/)
|
||||
|
||||
An opinionated code formatter that supports many languages.
|
||||
|
||||
```toml
|
||||
command = "prettier"
|
||||
options = ["--write"]
|
||||
includes = [
|
||||
"*.css",
|
||||
"*.html",
|
||||
"*.js",
|
||||
"*.json",
|
||||
"*.jsx",
|
||||
"*.md",
|
||||
"*.mdx",
|
||||
"*.scss",
|
||||
"*.ts",
|
||||
"*.yaml",
|
||||
]
|
||||
```
|
||||
|
||||
## [Black](https://github.com/psf/black)
|
||||
|
||||
A python formatter.
|
||||
|
||||
```toml
|
||||
command = "black"
|
||||
includes = ["*.py"]
|
||||
```
|
||||
|
||||
## [clang-format](https://clang.llvm.org/docs/ClangFormat.html)
|
||||
|
||||
A tool to format C/C++/Java/JavaScript/Objective-C/Protobuf/C# code.
|
||||
|
||||
```toml
|
||||
command = "clang-format"
|
||||
options = [ "-i" ]
|
||||
includes = [ "*.c", "*.cpp", "*.cc", "*.h", "*.hpp" ]
|
||||
```
|
||||
|
||||
Note: This example focuses on C/C++ but can be modified to use with other languages.
|
||||
|
||||
## Elm
|
||||
|
||||
```toml
|
||||
command = "elm-format"
|
||||
options = ["--yes"]
|
||||
includes = ["*.elm"]
|
||||
```
|
||||
|
||||
## Go
|
||||
|
||||
```toml
|
||||
command = "gofmt"
|
||||
options = ["-w"]
|
||||
includes = ["*.go"]
|
||||
```
|
||||
|
||||
## [Ormolu](https://github.com/tweag/ormolu)
|
||||
|
||||
Haskell formatter. Make sure to use ormolu 0.1.4.0+ as older versions don't
|
||||
adhere to the spec.
|
||||
|
||||
```toml
|
||||
command = "ormolu"
|
||||
options = [
|
||||
"--ghc-opt", "-XBangPatterns",
|
||||
"--ghc-opt", "-XPatternSynonyms",
|
||||
"--ghc-opt", "-XTypeApplications",
|
||||
"--mode", "inplace",
|
||||
"--check-idempotence",
|
||||
]
|
||||
includes = ["*.hs"]
|
||||
```
|
||||
|
||||
## [stylish-haskell](https://github.com/jaspervdj/stylish-haskell)
|
||||
|
||||
Another Haskell formatter.
|
||||
|
||||
```toml
|
||||
command = "stylish-haskell"
|
||||
options = [ "--inplace" ]
|
||||
includes = [ "*.hs" ]
|
||||
```
|
||||
|
||||
## [nixpkgs-fmt](https://github.com/nix-community/nixpkgs-fmt)
|
||||
|
||||
Nix code formatter.
|
||||
|
||||
```toml
|
||||
command = "nixpkgs-fmt"
|
||||
includes = ["*.nix"]
|
||||
```
|
||||
|
||||
## rustfmt
|
||||
|
||||
```toml
|
||||
command = "rustfmt"
|
||||
options = ["--edition", "2018"]
|
||||
includes = ["*.rs"]
|
||||
```
|
||||
|
||||
## [rufo](https://github.com/ruby-formatter/rufo)
|
||||
|
||||
Rufo is an opinionated ruby formatter. By default it exits with status 3 on
|
||||
file change so we have to pass the `-x` option.
|
||||
|
||||
```toml
|
||||
command = "rufo"
|
||||
options = ["-x"]
|
||||
includes = ["*.rb"]
|
||||
```
|
||||
|
||||
## cargo fmt
|
||||
|
||||
`cargo fmt` is not supported as it doesn't follow the spec. It doesn't allow
|
||||
to pass arbitrary files to be formatted, which treefmt relies on. Use `rustfmt`
|
||||
instead (which is what `cargo fmt` uses under the hood).
|
||||
|
||||
## [shfmt](https://github.com/mvdan/sh)
|
||||
|
||||
A shell code formatter.
|
||||
|
||||
```toml
|
||||
command = "shfmt"
|
||||
options = [
|
||||
"-i",
|
||||
"2", # indent 2
|
||||
"-s", # simplify the code
|
||||
"-w", # write back to the file
|
||||
]
|
||||
includes = ["*.sh"]
|
||||
```
|
||||
|
||||
## terraform
|
||||
|
||||
terraform fmt only supports formatting one file at the time. See
|
||||
https://github.com/hashicorp/terraform/pull/28191
|
||||
|
|
@ -11,11 +11,11 @@ hero:
|
|||
alt: Treefmt
|
||||
actions:
|
||||
- theme: brand
|
||||
text: Markdown Examples
|
||||
link: /markdown-examples
|
||||
text: Quick Start
|
||||
link: /quick-start
|
||||
- theme: alt
|
||||
text: API Examples
|
||||
link: /api-examples
|
||||
text: More Info
|
||||
link: /overview
|
||||
|
||||
features:
|
||||
- title: Feature A
|
||||
|
|
|
|||
65
docs/installation.md
Normal file
65
docs/installation.md
Normal file
|
|
@ -0,0 +1,65 @@
|
|||
---
|
||||
outline: deep
|
||||
---
|
||||
|
||||
# Installation
|
||||
|
||||
There are two options to install `treefmt`: by downloading the latest binary, or by compiling and building the tool from source.
|
||||
|
||||
## Installing with a binary file
|
||||
|
||||
You can find the list of the latest binaries [here](https://github.com/numtide/treefmt/releases).
|
||||
|
||||
## Building from source
|
||||
|
||||
There are several ways to build `treefmt` from source. Your choice will depend on whether you're a [nix](https://github.com/NixOS/nix) user.
|
||||
|
||||
### Non-Nix User
|
||||
|
||||
To try the project without building it, run:
|
||||
|
||||
```
|
||||
$ cargo run -- --help
|
||||
```
|
||||
|
||||
The command will output the manual. You can run the tool in this manner with any other flag or option to format your project.
|
||||
|
||||
To build a binary, you need to have rust installed. You can install it with [rustup](https://rustup.rs/). Now, if you want to build the project, switch to the project root folder and run:
|
||||
|
||||
```
|
||||
$ cargo build
|
||||
```
|
||||
|
||||
After the successful execution of the cargo build command, you will find the `treefmt` binary in the target folder.
|
||||
|
||||
### Nix User
|
||||
|
||||
[Nix](https://github.com/NixOS/nix) is a package manager foundational for NixOS. You can use it in NixOS and in any other OS equally.
|
||||
|
||||
If you're using both `treefmt` and `nix`, you can go for [`treefmt-nix`](https://github.com/numtide/treefmt-nix), a special tool that makes installation and configuration of `treefmt` with `nix` easier.
|
||||
|
||||
**Non-flake user**
|
||||
|
||||
Here you also have two options: you can install `treefmt` with plain nix-build , or with nix-shell.
|
||||
|
||||
To build the package with nix-build, just run:
|
||||
|
||||
```
|
||||
$ nix-build -A treefmt
|
||||
```
|
||||
|
||||
**Nix-flake user**
|
||||
|
||||
If you want to use this repository with flakes, please enable the flakes feature first. To run the project with flakes without building it, you can execute the following command in the root folder:
|
||||
|
||||
```
|
||||
$ nix run . -- --help
|
||||
```
|
||||
|
||||
To build the project, run the following command in the root folder:
|
||||
|
||||
```
|
||||
$ nix build
|
||||
```
|
||||
|
||||
The `treefmt` binary will be available in the result folder.
|
||||
|
|
@ -1,85 +0,0 @@
|
|||
# Markdown Extension Examples
|
||||
|
||||
This page demonstrates some of the built-in markdown extensions provided by VitePress.
|
||||
|
||||
## Syntax Highlighting
|
||||
|
||||
VitePress provides Syntax Highlighting powered by [Shiki](https://github.com/shikijs/shiki), with additional features like line-highlighting:
|
||||
|
||||
**Input**
|
||||
|
||||
````md
|
||||
```js{4}
|
||||
export default {
|
||||
data () {
|
||||
return {
|
||||
msg: 'Highlighted!'
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
````
|
||||
|
||||
**Output**
|
||||
|
||||
```js{4}
|
||||
export default {
|
||||
data () {
|
||||
return {
|
||||
msg: 'Highlighted!'
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Custom Containers
|
||||
|
||||
**Input**
|
||||
|
||||
```md
|
||||
::: info
|
||||
This is an info box.
|
||||
:::
|
||||
|
||||
::: tip
|
||||
This is a tip.
|
||||
:::
|
||||
|
||||
::: warning
|
||||
This is a warning.
|
||||
:::
|
||||
|
||||
::: danger
|
||||
This is a dangerous warning.
|
||||
:::
|
||||
|
||||
::: details
|
||||
This is a details block.
|
||||
:::
|
||||
```
|
||||
|
||||
**Output**
|
||||
|
||||
::: info
|
||||
This is an info box.
|
||||
:::
|
||||
|
||||
::: tip
|
||||
This is a tip.
|
||||
:::
|
||||
|
||||
::: warning
|
||||
This is a warning.
|
||||
:::
|
||||
|
||||
::: danger
|
||||
This is a dangerous warning.
|
||||
:::
|
||||
|
||||
::: details
|
||||
This is a details block.
|
||||
:::
|
||||
|
||||
## More
|
||||
|
||||
Check out the documentation for the [full list of markdown extensions](https://vitepress.dev/guide/markdown).
|
||||
60
docs/overview.md
Normal file
60
docs/overview.md
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
# About the project
|
||||
|
||||
`treefmt` is a formatting tool that saves you time: it provides developers with a universal way to trigger all formatters needed for the project in one place.
|
||||
|
||||
## Background
|
||||
|
||||
Typically, each project has its own code standards enforced by the project's owner. Any code contributions must match that given standard, i.e. be formatted in a specific manner.
|
||||
|
||||
At first glance, the task of code formatting may seem trivial: the formatter can be automatically triggered when you save a file in your IDE. Indeed, formatting doesn't take much effort if you're working on a single project long term: setting up the formatters in your IDE won't take much of your time, and then you're ready to go.
|
||||
|
||||
Contrary to that, if you're working on multiple projects at the same time, you may have to update your formatter configs in the IDE each time you switch between the projects. This is because formatter settings aren't project-specific --- they are set up globally for all projects.
|
||||
|
||||
Alternatively, you can trigger formatters manually, one-by-one or in a script. Actually, for bigger projects, it's common to have a script that runs over your project's directories and calls formatters consequently. But it takes time to iterate through all the files.
|
||||
|
||||
All the solutions take up a significant amount of time which a developer could spend doing the actual work. They also require you to remember which formatters and options are used by each project you are working on.
|
||||
|
||||
`treefmt` solves these issues.
|
||||
|
||||
## Why treefmt?
|
||||
|
||||
`treefmt`'s configuration is project-specific, so you don't need to re-configure formatters each time you switch between projects, like you have to when working with formatters in the IDE.
|
||||
|
||||
Contrary to calling formatters from the command line, there's no need to remember all the specific formatters required for each project. Once you set up the config, you can run the tool in any of your project's folders without any additional flags or options.
|
||||
|
||||
Typically, formatters have different ways to say there was a specific error. With `treefmt`, you get a standardized output which is easier to understand than the variegated outputs of different formatters, so it takes less time to grasp what's wrong.
|
||||
|
||||
In addition, `treefmt` works faster than the custom script solution because the changed files are cached and the formatters run only against them. Moreover, formatters are run in parallel, which makes the tool even faster.
|
||||
|
||||
The difference may not be significant for smaller projects, but it gets quite visible as the project grows. For instance, take the caching optimization. It takes 9 seconds to traverse a project of 1507 files and no changes without caching:
|
||||
|
||||
```
|
||||
traversed 1507 files
|
||||
matched 828 files to formatters
|
||||
left with 828 files after cache
|
||||
of whom 0 files were re-formatted
|
||||
all of this in 9s
|
||||
```
|
||||
|
||||
...while it takes 124 milliseconds to traverse the same project with caching:
|
||||
|
||||
```
|
||||
traversed 1507 files
|
||||
matched 828 files to formatters
|
||||
left with 0 files after cache
|
||||
of whom 0 files were re-formatted
|
||||
all of this in 124ms
|
||||
```
|
||||
|
||||
The tool can be invoked manually or integrated into your CI. There's currently no integration with IDEs, but the feature is coming soon.
|
||||
|
||||
## What we still need help with
|
||||
|
||||
- **IDE integration:** Most of developers are used to formatting a file upon save in the IDE. So far, you can't use `treefmt` for this purpose, but we're working on it 😀
|
||||
- **Pre-commit hook:** It's good to have your code checked for adherence to the project's standards before commit. `treefmt` pre-commit hook won't let you commit if you have formatting issues.
|
||||
- **Support of multiple formatters for one language:** In the current version, we advise you to avoid using multiple formatters for one and the same file type. This is because formatters are run in parallel and therefore may encounter issues while processing files. We are going to fix this issue soon, since there are cases when you may need more than one formatter per language.
|
||||
|
||||
As a next step, learn how to [install] and [use] `treefmt`.
|
||||
|
||||
[install]: installation.md
|
||||
[use]: usage.md
|
||||
14
docs/quick-start.md
Normal file
14
docs/quick-start.md
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
# Quick start
|
||||
|
||||
To run `treefmt` in your project, please follow these steps:
|
||||
|
||||
1. [Install] the tool.
|
||||
2. Install the needed formatters.
|
||||
3. Run `treefmt --init`. This will generate the basic configuration file `treefmt.toml` containing the formatting rules.
|
||||
4. Edit the configuration (see [here] how).
|
||||
5. Run `treefmt` with the needed flags and options. You can check the supported options by executing `treefmt --help`.
|
||||
|
||||
In the following sections we will guide you through installing and configuring `treefmt` in detail.
|
||||
|
||||
[install]: installation.md
|
||||
[here]: formatters-spec.md
|
||||
115
docs/usage.md
Normal file
115
docs/usage.md
Normal file
|
|
@ -0,0 +1,115 @@
|
|||
# Usage
|
||||
|
||||
You can run treefmt by executing:
|
||||
|
||||
`$ treefmt`
|
||||
|
||||
or, if it's not in your `$PATH`:
|
||||
|
||||
`$ ./treefmt`
|
||||
|
||||
Treefmt has the following specification:
|
||||
|
||||
```
|
||||
treefmt [FLAGS] [OPTIONS] [--] [paths]...
|
||||
```
|
||||
|
||||
## Flags
|
||||
|
||||
`--allow-missing-formatter`
|
||||
|
||||
> Do not exit with an error if some of the configured formatters are missing.
|
||||
|
||||
`--clear-cache`
|
||||
|
||||
> Reset the evaluation cache. Invalidation should happen automatically if the formatting tool has been updated, or if the files to format have changed. If cache wasn't properly invalidated, you can use this flag to clear the cache.
|
||||
|
||||
`--fail-on-change`
|
||||
|
||||
> Exit with error if some files require re-formatting. This is useful for your CI if you want to detect if the contributed code was forgotten to be formatted.
|
||||
|
||||
`-h, --help`
|
||||
|
||||
> Prints available flags and options
|
||||
|
||||
`--init`
|
||||
|
||||
> Creates a new config file `treefmt.toml`.
|
||||
|
||||
`--no-cache`
|
||||
|
||||
> Tells `treefmt` to ignore the evaluation cache entirely. With this flag, you can avoid cache invalidation issues, if any. Typically, the machine that is running treefmt in the CI is starting with a fresh environment each time, so any calculated cache is lost. The `--no-cache` flag eliminates unnecessary work in the CI.
|
||||
|
||||
`-q, --quiet`
|
||||
|
||||
> Don't print output to stderr.
|
||||
|
||||
`--stdin`
|
||||
|
||||
> Format the content passed in stdin.
|
||||
|
||||
`-V, --version`
|
||||
|
||||
> Print version information.
|
||||
|
||||
`-v, --verbose`
|
||||
|
||||
> Change the log verbosity. Log verbosity is based off the number of 'v' used. With one `-v`, your logs will display `[INFO]` and `[ERROR]` messages, while `-vv` will also show `[DEBUG]` messages.
|
||||
|
||||
`--config-file <config-file>`
|
||||
|
||||
> Run with the specified config file which is not in the project tree.
|
||||
|
||||
`-f, --formatters <formatters>...`
|
||||
|
||||
> Only apply selected formatters. Defaults to all formatters.
|
||||
|
||||
`-H, --hidden`
|
||||
|
||||
> Also traverse hidden files (files that start with a .). This behaviour can be overridden with the `--no-hidden` flag.
|
||||
|
||||
`--no-hidden`
|
||||
|
||||
> Override the `--hidden` flag. Don't traverse hidden files.
|
||||
|
||||
`--tree-root <tree-root>`
|
||||
|
||||
> Set the path to the tree root directory where treefmt will look for the files to format. Defaults to the folder holding the `treefmt.toml` file. It’s mostly useful in combination with `--config-file` to specify the project root which won’t coincide with the directory holding `treefmt.toml`.
|
||||
|
||||
`-C <work-dir>`
|
||||
|
||||
> Run as if `treefmt` was started in `<work-dir>` instead of the current working directory (default: `.`). Equivalent to `cd <work dir>; treefmt`.
|
||||
|
||||
## Arguments
|
||||
|
||||
`<paths>...`
|
||||
|
||||
> Paths to format. Defaults to formatting the whole tree
|
||||
|
||||
## CI integration
|
||||
|
||||
Typically, you would use treefmt in the CI with the `--fail-on-change` and `--no-cache flags`. Find the explanations above.
|
||||
|
||||
You can you set a `treefmt` job in the GitHub pipeline for Ubuntu with nix-shell like this:
|
||||
|
||||
```
|
||||
name: treefmt
|
||||
on:
|
||||
pull_request:
|
||||
push:
|
||||
branches: main
|
||||
jobs:
|
||||
formatter:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v1
|
||||
- uses: cachix/install-nix-action@v12
|
||||
with:
|
||||
nix_path: nixpkgs=channel:nixos-unstable
|
||||
- uses: cachix/cachix-action@v10
|
||||
with:
|
||||
name: nix-community
|
||||
authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
|
||||
- name: treefmt
|
||||
run: nix-shell --run "treefmt --fail-on-change --no-cache"
|
||||
```
|
||||
Reference in New Issue
Block a user