Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/denisraslov/folderslint
📁 Directory structure linter for Front-End projects
https://github.com/denisraslov/folderslint
directory-tree folder-structure javascript lint linter nodejs project-structure
Last synced: 18 days ago
JSON representation
📁 Directory structure linter for Front-End projects
- Host: GitHub
- URL: https://github.com/denisraslov/folderslint
- Owner: denisraslov
- License: mit
- Created: 2020-05-03T10:59:29.000Z (over 4 years ago)
- Default Branch: master
- Last Pushed: 2023-01-06T04:54:29.000Z (almost 2 years ago)
- Last Synced: 2024-10-15T17:46:32.130Z (about 1 month ago)
- Topics: directory-tree, folder-structure, javascript, lint, linter, nodejs, project-structure
- Language: JavaScript
- Homepage:
- Size: 635 KB
- Stars: 183
- Watchers: 6
- Forks: 3
- Open Issues: 6
-
Metadata Files:
- Readme: README.md
- Contributing: CONTRIBUTING.md
- License: LICENSE
Awesome Lists containing this project
README
# FoldersLint
Directory structure linter for Front-End projects
✅ Easily configured with simple rules in a single file
✅ Incredibly fast
✅ Support for Windows, MacOS and Linux
✅ Can be used with [lint-staged](https://github.com/okonet/lint-staged)
## Why
*Make you project sctructure pretty by linting it* 🗂
Directory structure rules are important part of any project. These rules help to raise clarity of the project and reduce its complexity. Having a clearly defined structure make developers always know where to put files and where to find them. If the project is big enough, it is necessary to avoid chaos in it.
`folderslint` let you configure directory structure rules and check if existed or new files fit these rules.
## Quick Overview
Install `folderslint` globally:
```sh
npm install -g folderslint
```Setup a config file `.folderslintrc` in the root of the project.
Run `folderslint` to check the whole project or a directory (i.e. `/components`):
```sh
folderslint components
```## Configuration
`folderslint` needs configuration file named `.folderslintrc` in the root of the project.The example of the config:
```js
{
"root": "src", // optional
"rules": [
"components/*",
"pages/components/*/utils",
"hooks",
"legacy/**"
]
}
````root` is the directory the structure of which should be checked.
`rules` is an array of rules which define permitted directory paths.
### Root directory
You have to specify `root` if you want to check structure in a specific directory. Directories which are out of the `root` will not be checked.
If you want all the directories of the project to be checked, you don't need to specify `root`.### Rules syntax
There are 3 ways to specify a rule:
- the exact path of a directory,
- `*` instead of a directory name if any directory accepted on that level,
- `**` **at the end of a rule** instead of a directory name if any directory accepted on any lower level.⚠️ `**` **can be used only at the end of a rule** because it doesn't make sense to use it at the middle of a rule. It would make any number of nested directories in the middle of a path accepted which gives too much flexibility for the idea of clearly defined directory structure rules.
For example:
Rule | Meaning
--- | ---
`hooks` | ✅ The directory `hooks` (and files in it) is accepted.
❌ Any nested directory is not accepted.
`components/*` | ✅ The directory `components` is accepted.
✅ Any *first level* nested directory is accepted.
❌ Any *second level* nested directory is not accepted.
`components/*/utils` | ✅ The directory `components` is accepted.
✅ Any *first level* nested directory is accepted.
✅ The *second level* nested directory `utils` is accepted.
❌ Any other *second level* nested directory is not accepted.
`legacy/**` | ✅ The directory `legacy` is accepted.
✅ Any nested directory on *any level* is accepted.
`components/*/legacy/**` | ✅ The directory `components` is accepted.
✅ Any *first level* nested directory is accepted.
✅ The *second level* nested directory `legacy` is accepted.
❌ Any other *second level* nested directory is not accepted.
✅ Any nested directory on *any level* inside of *legacy* directory is accepted.⚠️ A rule like `components/*/utils` automatically make the `components` and `components/*` rules work. So, no need to specify a rule for every level directory. You need to specify the deepest path.
⚠️ It's not recommended to overuse `**` pattern. It lets absence of structure to sprout in your project. Still it could be useful for some directories which have messy structure by its nature - i.e. `node_modules`, not maintained legacy directories.
## Usage with [lint-staged](https://github.com/okonet/lint-staged)
It is handy to use `folderslint` together with `lint-staged`. In this case `folderslint` checks only the files which were modified for a commit.For that, add `folderslint` to the `lint-staged` section of your `package.json`.
For example, this is how `package.json` can look like if you want to run `folderslint` as a pre-commit hook via [husky](https://github.com/typicode/husky) tool:
```json
"husky": {
"hooks": {
"pre-commit": "lint-staged",
}
},
"lint-staged": {
"*.{js,ts,tsx}": [
"folderslint"
]
}
```