Linter for monorepos. Checks folder structure, module contents, file contents and naming conventions of a monorepo.
This tool will look for modules inside the repo (which are folders with a certain "marker file", like package.json). After discovering the module folders, it will run a set a rules to check if the modules are well structured and show the results.
Some example of the rules are: check if all modules are inside a certain folder, check if module names comply to a specific naming convention, check if certain file between modules have the same contents, check if github actions workflow name contains the name of the corresponding module...
This project follows the Poppins manifesto guidelines as part of it's community principles and policies, focusing all the decisions and interactions on providing open source beginners mentorship with real and relevant experiences, respecting each learning pace, background experience, academic formation, questions, suggestions, doubts and opinion.
So, let's start contributing! Open an issue asking for a task to be done by you. A mentor/maintainer will come and provide a technical overview of the project and what are the possibles ways of contributing to the project. You will discuss the options and a suitable issue will be assigned or created to you.
Monolint was implemented in an extensible way for creating more and more rules as needed, so if you new a new feature, contribute to our project! Read CONTRIBUTING.md for more details.
If you work or know a good public monorepo, please let us now so we can use it as a reference test for this tool!
Check rules documentation here
Simplest run
npx monolint .
inside the repo dirCustomize rules
{
"module-markers": ["package.json"],
"rules": {
"packagejson-same-name": false
}
}
Show command line help: npx monolint --help
npx monolint .
Create this file for configuring monolint
This file normally is at the root of our monorepo, but you can place it in intermediary folders or in the module itself to setup specific configurations for the different parts of the monorepo
The structure of this file is
{
"extends": ["monolint:basic", "monolint:serverless"]
"module-markers": ["package.json"],
"use-gitignore": true,
"rules": {
"packagejson-same-name": true
}
}
'module-markers' - declare a list of file names that, if found in any folder inside the monorepo, will make the folder considered a module. Used only in the base folder of the monorepo.
'use-gitignore' - whatever use .gitignore (is exists) as the starting point for defining the patterns (along with .monolintignore) for ignore paths during module search. Defaults to true
'rules' - activate/deactivate rules, or setup specific configurations for a rule
'extends' - list of pre-defined configurations to be merged into this one. If not defined, 'monolint:recommended' will be used. Can be one of:
This file can be placed in any folder to define specific configurations/rules for different branches of the monorepo.
Create file ".monolintignore" at the root folder of the monorepo with file/directory patterns to be ignored during module discovery. You can use these patterns to hide entire branches of the monorepo from monolint or just specific directories.
By default all patterns present in .gitignore at the root of the monorepo will be used for ignoring paths during module discovery. You can disable this behavior with the configuration 'use-gitignore': false in .monolint.json
The ignore patterns works as follows:
Example
modules/
⌞ auth-svc/
⌞ todo-web/
shared/
⌞ utils/
lib/test/external/
⌞ legacy
⌞ platform
.monolintignore
**/legacy
modules/auth-svc
shared
modules/
⌞ todo-web/
lib/test/external/
⌞ platform
Each check that you want to do in the monorepo is done by a "rule". You can enable/disable/configure then in .monolint.json configuration file.
Check rules documentation here