Lint and maintain many projects at once
Like ESLint for your entire computer and more than just JavaScript.
- Some of us have a lot of modules.
- We often want to change multiple modules simultaneously.
- Helps you scale and keep track of todos across projects.
- Easy maintenance means happy developers and users.
npm install mop-cli --global
$ mop --help
Usage
$ mop [rule-name]
Option
--cwd Working directory to search for projects
--reporter How to display and stylize results
Example
$ mop caret-deps
$ mop caret-deps --reporter=eslint
Tip: On Node < 7.6, mop
needs to be node --harmony "$(which mop)"
See the list of rules to change what triggers mop
to complain.
A project is an object with name
, path
and pkg
properties.
Type: string
Either pkg.name
if it is available or the basename of the project's path
.
Type: string
Filepath of the project's root directory.
Type: object
, null
Parsed package.json found within path
, or null
if the file is missing. An error will be thrown if the file is present but cannot be read or is invalid.
Projects are enhanced with the following properties before they are returned to users.
Type: Array<Problem>
A list of all rule violations the project is responsible for.
Type: Array<Problem>
Same as problems
, but only those whose severity
is error
.
Type: Array<Problem>
Same as problems
, but only those whose severity
is warn
.
Each rule may optionally return a problem descriptor, which represents a rule violation. The only required property is message
.
Type: string
A message describing the problem.
Type: string
Filepath that is responsible for the problem.
Type: number
A positive, zero-based integer within the file where the problem occurred.
Type: number
A positive, zero-based integer within the line where the problem occurred.
Type: any
Arbitrary data that reporters can use to enhance output.
Problems are enhanced with the following properties before they are returned to users.
Type: string
The rule that reported the problem.
Type: string
Example: warn
The problem level, as configured by the user for the rule.
Returns a problem or an Array
of problems, optionally wrapped in a Promise
, if the project violates the expectations of the rule.
Learn more about rules by creating one.
Type: object
A project for the rule to check.
Custom arguments for the rule provided by the user in their configuration. Most rules that use this accept just a single option
object with properties for configuring the rule.
Returns a Promise
for an Array
of project results with lists of rule violations.
Type: string
Default: process.cwd()
Final directory in a downwards search for projects. Only used when no projects
are provided.
Type: Array<Project>
List of projects to lint.
Type: object
Map of rules to apply and their arguments. Compatible with ESLint conventions.
Example:
{
'caret-deps' : 'warn',
foo : ['error', 'blah']
}
Because Mop checks many projects at once, enabling a single rule can cause many more errors to be reported than in tools like ESLint that check a single project. THis is good, as it gives you a high level view of where fixes are needed. However, when you are initially configuring Mop, you should enable rules one at a time in order to avoid being overwhelmed.
Mop checks every project it can find, whereas ESLint only checks a single project. Mop also doesn't care what language you use, although it is optimized for JavaScript projects. It is actually more like clinton than ESLint, but people are more familiar with ESLint, hence the comparison.
- clinton - Project style linter for individual projects
- XO - JavaScript linter for individual projects
- Stylelint - CSS linter for individual projects
See our contributing guidelines for more details.
- Fork it.
- Make a feature branch:
git checkout -b my-new-feature
- Commit your changes:
git commit -am 'Add some feature'
- Push to the branch:
git push origin my-new-feature
- Submit a pull request.
Go make something, dang it.