Repository: lint-staged/lint-staged (language: javascript)

Issue:
Naming confusion: linters are not always used as formatters
I know will probably be closed as _"it's way too late to do anything about it now"_ 😅, but - _"linter"_ and _"formatter"_ are not always the same thing. Since `lint-staged` became popular:

* The JS ecosystem largely switched to [Prettier](https://prettier.io) -or, recently, other dedicated formatters- for formatting
* ESLint and typescript-eslint started recommending _not_ using linters for formatting:
  * https://eslint.org/blog/2023/10/deprecating-formatting-rules
  * https://typescript-eslint.io/blog/deprecating-formatting-rules
* With "cross-file linting" such as [typescript-eslint-style typed linting](https://typescript-eslint.io/getting-started/typed-linting) and [`eslint-plugin-import`-style import analysis](https://github.com/import-js/eslint-plugin-import), linting just changed files actually isn't enough to fully lint files: changes in one file might impact lint results in theoretically _any other file in the project_ 

As a result, a lot of projects have switched away from using Husky and `lint-staged` for linters. A lot of us just use it for formatters such as Prettier, and instead just have linters running in editors and in CI.

Suggestion: can at least the docs for lint-staged be updated to not specifically refer to linters? I'd be happy to send a PR!

```diff
- 🚫💩 — Run linters on git staged files
+ 🚫💩 — Run code checkers on git staged files
```

Note: I'm _not_ trying to proclaim here that people shouldn't use lint-staged for linters. I'm just trying to suggest that describing this project as _primarily_ for running linters on staged files is confusing given that that's _no longer_ the primary use case in the world.

lint-staged is a great+useful project and I think it's a testament to how well it's built that, almost a decade after first release, it's still so widely used! ❤ 


Discussion / hints:
We could describe _lint-staged_ as a task runner for running any command on git staged files, filtered by a glob.

Yeah I agree the name is rather specific, but then again this tool aims to be simple and I'm pretty sure if it was renamed to like "_staged-tasks_", there would be so many feature requests and complex setups leading to user error.

That said, feel free to open a PR for more general language towards "tasks, like linters and formatters". 👍 

BTW, most of the examples already use `eslint --fix` and `prettier --write`.
I agree with everything you said and also am happy to accept the proposed change. 

Fix patch:
diff --git a/.changeset/tiny-pots-care.md b/.changeset/tiny-pots-care.md
new file mode 100644
index 000000000..a845151cc
--- /dev/null
+++ b/.changeset/tiny-pots-care.md
@@ -0,0 +1,2 @@
+---
+---
diff --git a/README.md b/README.md
index 8d25b3fff..04afaddc0 100644
--- a/README.md
+++ b/README.md
@@ -4,7 +4,7 @@
 
 ---
 
-Run linters against staged git files and don't let :poop: slip into your code base!
+Run tasks like formatters and linters against staged git files and don't let :poop: slip into your code base!
 
 ```bash
 npm install --save-dev lint-staged # requires further setup
@@ -36,7 +36,7 @@ $ git commit
 
 ## Why
 
-Linting makes more sense when run before committing your code. By doing so you can ensure no errors go into the repository and enforce code style. But running a lint process on a whole project is slow, and linting results can be irrelevant. Ultimately you only want to lint files that will be committed.
+Code quality tasks like formatters and linters make more sense when run before committing your code. By doing so you can ensure no errors go into the repository and enforce code style. But running a task on a whole project can be slow, and opinionated tasks such as linting can sometimes produce irrelevant results. Ultimately you only want to check files that will be committed.
 
 This project contains a script that will run arbitrary shell tasks with a list of staged files as an argument, filtered by a specified glob pattern.
 
@@ -59,8 +59,8 @@ To install _lint-staged_ in the recommended way, you need to:
 1. Set up the `pre-commit` git hook to run _lint-staged_
    - [Husky](https://github.com/typicode/husky) is a popular choice for configuring git hooks
    - Read more about git hooks [here](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)
-1. Install some linters, like [ESLint](https://eslint.org) or [Prettier](https://prettier.io)
-1. Configure _lint-staged_ to run linters and other tasks:
+1. Install some tools like [ESLint](https://eslint.org) or [Prettier](https://prettier.io)
+1. Configure _lint-staged_ to run code checkers and other tasks:
    - for example: `{ "*.js": "eslint" }` to run ESLint for all staged JS files
    - See [Configuration](#configuration) for more info
 
@@ -142,7 +142,7 @@ Any lost modifications can be restored from a git stash:
   > git stash apply --index stash@{0}
 ```
 
-- **`--allow-empty`**: By default, when linter tasks undo all staged changes, lint-staged will exit with an error and abort the commit. Use this flag to allow creating empty git commits.
+- **`--allow-empty`**: By default, when tasks undo all staged changes, lint-staged will exit with an error and abort the commit. Use this flag to allow creating empty git commits.
 - **`--concurrent [number|boolean]`**: Controls the [concurrency of tasks](#task-concurrency) being run by lint-staged. **NOTE**: This does NOT affect the concurrency of subtasks (they will always be run sequentially). Possible values are:
   - `false`: Run all tasks serially
   - `true` (default) : _Infinite_ concurrency. Runs as many tasks in parallel as possible.
@@ -153,14 +153,14 @@ Any lost modifications can be restored from a git stash:
   - uses [debug](https://github.com/visionmedia/debug) internally to log additional information about staged files, commands being executed, location of binaries, etc. Debug logs, which are automatically enabled by passing the flag, can also be enabled by setting the environment variable `$DEBUG` to `lint-staged*`.
   - uses [`verbose` renderer](https://listr2.kilic.dev/renderers/verbose-renderer/) for `listr2`; this causes serial, uncoloured output to the terminal, instead of the default (beautified, dynamic) output.
     (the [`verbose` renderer](https://listr2.kilic.dev/renderers/verbose-renderer/) can also be activated by setting the `TERM=dumb` or `NODE_ENV=test` environment variables)
-- **`--diff`**: By default linters are filtered against all files staged in git, generated from `git diff --staged`. This option allows you to override the `--staged` flag with arbitrary revisions. For example to get a list of changed files between two branches, use `--diff="branch1...branch2"`. You can also read more from about [git diff](https://git-scm.com/docs/git-diff) and [gitrevisions](https://git-scm.com/docs/gitrevisions). This option also implies `--no-stash`.
+- **`--diff`**: By default tasks are filtered against all files staged in git, generated from `git diff --staged`. This option allows you to override the `--staged` flag with arbitrary revisions. For example to get a list of changed files between two branches, use `--diff="branch1...branch2"`. You can also read more from about [git diff](https://git-scm.com/docs/git-diff) and [gitrevisions](https://git-scm.com/docs/gitrevisions). This option also implies `--no-stash`.
 - **`--diff-filter`**: By default only files that are _added_, _copied_, _modified_, or _renamed_ are included. Use this flag to override the default `ACMR` value with something else: _added_ (`A`), _copied_ (`C`), _deleted_ (`D`), _modified_ (`M`), _renamed_ (`R`), _type changed_ (`T`), _unmerged_ (`U`), _unknown_ (`X`), or _pairing broken_ (`B`). See also the `git diff` docs for [--diff-filter](https://git-scm.com/docs/git-diff#Documentation/git-diff.txt---diff-filterACDMRTUXB82308203).
 - **`--max-arg-length`**: long commands (a lot of files) are automatically split into multiple chunks when it detects the current shell cannot handle them. Use this flag to override the maximum length of the generated command string.
 - **`--no-stash`**: By default a backup stash will be created before running the tasks, and all task modifications will be reverted in case of an error. This option will disable creating the stash, and instead leave all modifications in the index when aborting the commit. Can be re-enabled with `--stash`. This option also implies `--no-hide-partially-staged`.
 - **`--no-hide-partially-staged`**: By default, unstaged changes from partially staged files will be hidden. This option will disable this behavior and include all unstaged changes in partially staged files. Can be re-enabled with `--hide-partially-staged`
 - **`--quiet`**: Supress all CLI output, except from tasks.
 - **`--relative`**: Pass filepaths relative to `process.cwd()` (where `lint-staged` runs) to tasks. Default is `false`.
-- **`--shell`**: By default linter commands will be parsed for speed and security. This has the side-effect that regular shell scripts might not work as expected. You can skip parsing of commands with this option. To use a specific shell, use a path like `--shell "/bin/bash"`.
+- **`--shell`**: By default task commands will be parsed for speed and security. This has the side-effect that regular shell scripts might not work as expected. You can skip parsing of commands with this option. To use a specific shell, use a path like `--shell "/bin/bash"`.
 - **`--verbose`**: Show task output even when tasks succeed. By default only failed output is shown.
 
 ## Configuration
@@ -282,7 +282,7 @@ Or, if necessary, you can limit the concurrency using `--concurrent <number>` or
 
 ## Filtering files
 
-Linter commands work on a subset of all staged files, defined by a _glob pattern_. lint-staged uses [micromatch](https://github.com/micromatch/micromatch) for matching files with the following rules:
+Task commands work on a subset of all staged files, defined by a _glob pattern_. lint-staged uses [micromatch](https://github.com/micromatch/micromatch) for matching files with the following rules:
 
 - If the glob pattern contains no slashes (`/`), micromatch's `matchBase` option will be enabled, so globs match a file's basename regardless of directory:
   - `"*.js"` will match all JS files, like `/test.js` and `/foo/bar/test.js`
@@ -297,9 +297,9 @@ When matching, lint-staged will do the following
 - Resolve the git root automatically, no configuration needed.
 - Pick the staged files which are present inside the project directory.
 - Filter them using the specified glob patterns.
-- Pass absolute paths to the linters as arguments.
+- Pass absolute paths to the tasks as arguments.
 
-**NOTE:** `lint-staged` will pass _absolute_ paths to the linters to avoid any confusion in case they're executed in a different working directory (i.e. when your `.git` directory isn't the same as your `package.json` directory).
+**NOTE:** `lint-staged` will pass _absolute_ paths to the tasks to avoid any confusion in case they're executed in a different working directory (i.e. when your `.git` directory isn't the same as your `package.json` directory).
 
 Also see [How to use `lint-staged` in a multi-package monorepo?](#how-to-use-lint-staged-in-a-multi-package-monorepo)
 
@@ -589,12 +589,12 @@ The following is equivalent:
 
 </details>
 
-### Use environment variables with linting commands
+### Use environment variables with task commands
 
 <details>
   <summary>Click to expand</summary>
 
-Linting commands _do not_ support the shell convention of expanding environment variables. To enable the convention yourself, use a tool like [`cross-env`](https://github.com/kentcdodds/cross-env).
+Task commands _do not_ support the shell convention of expanding environment variables. To enable the convention yourself, use a tool like [`cross-env`](https://github.com/kentcdodds/cross-env).
 
 For example, here is `jest` running on all `.js` files with the `NODE_ENV` variable being set to `"test"`:
 
@@ -849,7 +849,7 @@ _Thanks to [this comment](https://youtrack.jetbrains.com/issue/IDEA-135454#comme
 <details>
   <summary>Click to expand</summary>
 
-Install _lint-staged_ on the monorepo root level, and add separate configuration files in each package. When running, _lint-staged_ will always use the configuration closest to a staged file, so having separate configuration files makes sure linters do not "leak" into other packages.
+Install _lint-staged_ on the monorepo root level, and add separate configuration files in each package. When running, _lint-staged_ will always use the configuration closest to a staged file, so having separate configuration files makes sure tasks do not "leak" into other packages.
 
 For example, in a monorepo with `packages/frontend/.lintstagedrc.json` and `packages/backend/.lintstagedrc.json`, a staged file inside `packages/frontend/` will only match that configuration, and not the one in `packages/backend/`.
 
@@ -887,7 +887,7 @@ To support backwards-compatibility, monorepo features require multiple _lint-sta
 
 tl;dr: Yes, but the pattern should start with `../`.
 
-By default, `lint-staged` executes linters only on the files present inside the project folder(where `lint-staged` is installed and run from).
+By default, `lint-staged` executes tasks only on the files present inside the project folder(where `lint-staged` is installed and run from).
 So this question is relevant _only_ when the project folder is a child folder inside the git repo.
 In certain project setups, it might be desirable to bypass this restriction. See [#425](https://github.com/okonet/lint-staged/issues/425), [#487](https://github.com/okonet/lint-staged/issues/487) for more context.
 
diff --git a/lib/index.js b/lib/index.js
index 538b5cf74..d78ccaec4 100644
--- a/lib/index.js
+++ b/lib/index.js
@@ -62,7 +62,7 @@ const getMaxArgLength = () => {
  * @param {boolean} [options.verbose] - Show task output even when tasks succeed; by default only failed output is shown
  * @param {Logger} [logger]
  *
- * @returns {Promise<boolean>} Promise of whether the linting passed or failed
+ * @returns {Promise<boolean>} Promise of whether the task passed or failed
  */
 const lintStaged = async (
   {
diff --git a/lib/types.d.ts b/lib/types.d.ts
index 15050912d..59229aa04 100644
--- a/lib/types.d.ts
+++ b/lib/types.d.ts
@@ -93,7 +93,7 @@ type Logger = {
 }
 
 /**
- * @returns {boolean} `true` when linting was successful, `false` when some tasks failed with errors
+ * @returns {boolean} `true` when all tasks were successful, `false` when some tasks failed with errors
  * @throws {Error} when failed to some other errors
  */
 type lintStaged = (options: Options, logger?: Logger) => Promise<boolean>


Test patch:
diff --git a/test/e2e/special-characters.test.js b/test/e2e/special-characters.test.js
index a04ef8124..c32ba043b 100644
--- a/test/e2e/special-characters.test.js
+++ b/test/e2e/special-characters.test.js
@@ -13,7 +13,7 @@ describe('lint-staged', () => {
   }
 
   test.each([['$test.js'], ['[test].js'], ['(test).js']])(
-    'supports linting "%s" with ESLint + Prettier',
+    'supports running "%s" with ESLint + Prettier',
     async (filename) =>
       withGitIntegration(async ({ cwd, execGit, readFile, writeFile }) => {
         const lintStaged = getLintStagedExecutor(cwd)
diff --git a/test/unit/generateTasks.spec.js b/test/unit/generateTasks.spec.js
index 097797ed2..95669b5fa 100644
--- a/test/unit/generateTasks.spec.js
+++ b/test/unit/generateTasks.spec.js
@@ -62,7 +62,7 @@ describe('generateTasks', () => {
     })
   })
 
-  it('should return an empty file list for linters with no matches.', async () => {
+  it('should return an empty file list for tasks with no matches.', async () => {
     const result = await generateTasks({ config, cwd, files })
 
     result.forEach((task) => {
diff --git a/test/unit/resolveTaskFn.spec.js b/test/unit/resolveTaskFn.spec.js
index e0cafeb50..1abda7018 100644
--- a/test/unit/resolveTaskFn.spec.js
+++ b/test/unit/resolveTaskFn.spec.js
@@ -176,7 +176,7 @@ describe('resolveTaskFn', () => {
     })
   })
 
-  it('should throw error for failed linters', async () => {
+  it('should throw error for failed tasks', async () => {
     expect.assertions(1)
     execa.mockReturnValueOnce(
       mockExecaReturnValue({
diff --git a/test/unit/runAll.spec.js b/test/unit/runAll.spec.js
index 9a4631b23..dee1c8141 100644
--- a/test/unit/runAll.spec.js
+++ b/test/unit/runAll.spec.js
@@ -162,7 +162,7 @@ describe('runAll', () => {
     expect(console.printHistory()).toMatch(/"data":"SKIPPED".*Running tasks for staged files/)
   })
 
-  it('should skip applying unstaged modifications if there are errors during linting', async () => {
+  it('should skip applying unstaged modifications if there are errors during a task', async () => {
     expect.assertions(2)
 
     getStagedFiles.mockImplementationOnce(async () => ['sample.js'])