Lint and maintain many projects at once
npm install mop-cli> Lint and maintain many projects at once
Like ESLint for your entire computer and more than just JavaScript.
- Why?
- Install
- Usage
- Rules
- Data Types
- API
- Tips
- FAQ
- Related
- Contributing
- License
- 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.
``sh`
npm install mop-cli --global
`console
$ 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.
#### name
Type: string
Either pkg.name if it is available or the basename of the project's path.
#### path
Type: string
Filepath of the project's root directory.
#### pkg
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.
#### problems
Type: Array
A list of all rule violations the project is responsible for.
#### errors
Type: Array
Same as problems, but only those whose severity is error.
#### warnings
Type: Array
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.
#### message
Type: string
A message describing the problem.
#### path
Type: string
Filepath that is responsible for the problem.
#### line
Type: number
A positive, zero-based integer within the file where the problem occurred.
#### column
Type: number
A positive, zero-based integer within the line where the problem occurred.
#### data
Type: any
Arbitrary data that reporters can use to enhance output.
---
Problems are enhanced with the following properties before they are returned to users.
#### ruleId
Type: string
The rule that reported the problem.
#### severity
Type: string
Example:
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.
#### project
Type: object
A project for the rule to check.
#### args
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.
#### cwd
Type: string
Default:
Final directory in a downwards search for projects. Only used when no projects are provided.
#### projects
Type: Array
List of projects to lint.
#### rule
Type: object
Map of rules to apply and their arguments. Compatible with ESLint conventions.
Example:
`js`
{
'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.
1. Fork it.
2. Make a feature branch: git checkout -b my-new-feature
3. Commit your changes:
4. Push to the branch:
5. Submit a pull request.
Go make something, dang it.