Lint and maintain many projects at once
- 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 --helpUsage$ mop [rule-name]Option--cwd Working directory to search for projects--reporter How to display and stylize resultsExample$ 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
pkg.name if it is available or the basename of the project's
Filepath of the project's root directory.
Parsed package.json found within
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.
A list of all rule violations the project is responsible for.
problems, but only those whose
problems, but only those whose
Each rule may optionally return a problem descriptor, which represents a rule violation. The only required property is
A message describing the problem.
Filepath that is responsible for the problem.
A positive, zero-based integer within the file where the problem occurred.
A positive, zero-based integer within the line where the problem occurred.
Arbitrary data that reporters can use to enhance output.
Problems are enhanced with the following properties before they are returned to users.
The rule that reported the problem.
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.
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.
Promise for an
Array of project results with lists of rule violations.
Final directory in a downwards search for projects. Only used when no
projects are provided.
List of projects to lint.
Map of rules to apply and their arguments. Compatible with ESLint conventions.
'caret-deps' : 'warn'foo : 'error' 'blah'
Enable rules gently
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.
How is this different than ESLint?
- clinton - Project style 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.