JavaScript Code Quality and Formatting Tools
eslint, jshint, and jslint are linters that find errors and enforce style rules, while prettier is a code formatter that automatically fixes layout issues. eslint is the industry standard for customizable linting, supporting modern JavaScript features and plugins. jshint is a simpler linter often used for legacy code or quick checks. jslint is an older tool with rigid rules that is rarely used in modern teams. prettier focuses solely on code appearance, often working alongside a linter to handle style concerns separately.
Npm Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
ESLint vs JSHint vs JSLint vs Prettier: Code Quality Compared
Keeping JavaScript code clean and error-free requires the right tools. eslint, jshint, and jslint focus on finding bugs and enforcing logic rules, while prettier focuses on fixing code style automatically. Understanding their differences helps you build a workflow that catches errors without slowing down development.
๐๏ธ Configuration Files: Flexibility vs Rigidity
How you configure these tools defines how much control you have over their behavior.
eslint uses a dedicated config file that supports JavaScript, JSON, or YAML.
- You can define rules, environments, and plugins.
- Modern versions support
eslint.config.js(Flat Config) for better performance.
// eslint: eslint.config.js
export default [
{
rules: {
"no-unused-vars": "error"
}
}
];
jshint uses a JSON file named .jshintrc.
- Options are simpler and less extensible.
- Good for basic checks without complex setup.
// jshint: .jshintrc
{
"unused": true,
"eqeqeq": true
}
jslint often relies on inline comments or a simple .jslintrc.
- Configuration is very limited.
- Most settings are hardcoded by the tool author.
// jslint: Inline comment
/*jslint browser: true, node: true */
function init() { /*...*/ }
prettier uses .prettierrc for style options only.
- You control line width, quotes, and semicolons.
- It does not check for logic errors.
// prettier: .prettierrc
{
"semi": true,
"singleQuote": true
}
๐ Running the Tool: CLI Commands
Each package provides a command-line interface to check or fix your code.
eslint runs via the eslint command.
- You can point it at files or folders.
- Use
--fixto automatically correct some issues.
# eslint: Run on current directory
npx eslint . --fix
jshint runs via the jshint command.
- Similar usage to ESLint but fewer options.
- Does not support auto-fixing for most rules.
# jshint: Run on current directory
npx jshint .
jslint runs via the jslint command.
- Output is strict and often verbose.
- Rarely used in automated pipelines today.
# jslint: Run on specific file
npx jslint app.js
prettier runs via the prettier command.
- Use
--writeto save changes directly to files. - Focuses only on formatting, not logic.
# prettier: Format all files
npx prettier --write .
๐ซ Ignoring Files: Excluding Paths
Large projects often need to skip specific folders or generated code.
eslint uses .eslintignore or ignorePatterns in config.
- Supports glob patterns for flexible matching.
- Can ignore node_modules by default.
# eslint: .eslintignore
build/
coverage/
*.min.js
jshint uses .jshintignore.
- Simple text file with paths.
- Less flexible than ESLint but sufficient for most cases.
# jshint: .jshintignore
vendor/
dist/
jslint lacks a standard ignore file.
- You must exclude files via CLI arguments.
- This makes automation harder in large projects.
# jslint: Exclude via CLI
npx jslint app.js --exclude vendor/
prettier uses .prettierignore.
- Works similarly to
.gitignore. - Ensures generated code is not reformatted.
# prettier: .prettierignore
build/
*.lock
๐ Inline Disables: Suppressing Rules
Sometimes you need to bypass a rule for a specific line of code.
eslint allows fine-grained disables with comments.
- You can disable all rules or specific ones.
- Recommended to use sparingly.
// eslint: Disable line
// eslint-disable-next-line no-unused-vars
const unused = 1;
jshint supports inline ignores with comments.
- Syntax is simpler but less specific.
- Useful for known false positives.
// jshint: Ignore line
// jshint ignore:line
const unused = 1;
jslint does not support inline disables well.
- The tool expects code to conform strictly.
- This rigidity is why many teams avoid it.
// jslint: No standard inline disable
// Must adjust global settings instead
const unused = 1; // Will likely trigger error
prettier allows ignoring specific blocks.
- Useful for keeping manual formatting in place.
- Does not affect logic checks.
// prettier: Ignore format
// prettier-ignore
const messy = { a:1,b:2 };
๐ Modern JavaScript Support
Support for new language features is critical for modern development.
| Package | ES6+ Support | JSX/React | TypeScript | Configurable |
|---|---|---|---|---|
eslint | โ Full | โ Yes | โ Yes | โ High |
jshint | โ ๏ธ Partial | โ ๏ธ Limited | โ No | โ ๏ธ Medium |
jslint | โ Low | โ No | โ No | โ Low |
prettier | โ Full | โ Yes | โ Yes | โ ๏ธ Style Only |
โ ๏ธ Deprecation and Maintenance Status
jslint should NOT be used in new projects.
- It is considered obsolete for team environments due to lack of flexibility.
- Evaluate
eslintinstead for better long-term support.
jshint is maintained but less active.
- Suitable for legacy projects already using it.
- New projects should prefer
eslintfor richer features.
eslint and prettier are actively maintained.
- They are the standard choice for modern JavaScript development.
- Using them together provides both logic checks and style consistency.
๐ก The Big Picture
eslint is the core tool for catching errors and enforcing logic rules. It is flexible enough to adapt to any project size or framework. Use it as your primary quality gate.
prettier is the best choice for handling code style automatically. It removes debates about formatting during code reviews. Pair it with ESLint for complete coverage.
jshint has a place in legacy maintenance but lacks modern features. Use it only if migrating an old project where switching costs are too high.
jslint is historically significant but practically outdated. Avoid it for new work to prevent unnecessary friction with your team.
Final Thought: For most teams, the combination of eslint for logic and prettier for style offers the best balance. This setup catches bugs early while keeping code consistent without manual effort.
How to Choose: prettier vs jslint vs eslint vs jshint
- prettier:
Choose
prettierto automatically handle code formatting so your team does not argue about spaces or semicolons. It works best when paired with a linter like ESLint to handle code quality separately from style. This separation reduces configuration complexity and speeds up code reviews. - jslint:
Avoid
jslintfor new projects because its rules are too strict and cannot be easily changed to fit team preferences. It is mostly relevant for historical context or specific personal preferences aligned with its original author. Modern teams usually find it too restrictive for collaborative work. - eslint:
Choose
eslintfor most modern projects where you need flexible rules, support for new JavaScript features, and integration with frameworks like React or Vue. It allows you to catch logic errors and enforce coding standards without sacrificing configurability. The ecosystem is vast, offering plugins for almost any need. - jshint:
Choose
jshintif you are maintaining older codebases that already rely on it or need a lightweight checker for simple scripts. It is less configurable than ESLint but requires minimal setup for basic error detection. It works well for projects that do not need complex rule customization.
Popular Comparisons
README for prettier
Opinionated Code Formatter
JavaScript
ยท TypeScript
ยท Flow
ยท JSX
ยท JSON
CSS
ยท SCSS
ยท Less
HTML
ยท Vue
ยท Angular
GraphQL
ยท Markdown
ยท YAML
Your favorite language?
Intro
Prettier is an opinionated code formatter. It enforces a consistent style by parsing your code and re-printing it with its own rules that take the maximum line length into account, wrapping code when necessary.
Input
foo(reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne());
Output
foo(
reallyLongArg(),
omgSoManyParameters(),
IShouldRefactorThis(),
isThereSeriouslyAnotherOne(),
);
Prettier can be run in your editor on-save, in a pre-commit hook, or in CI environments to ensure your codebase has a consistent style without devs ever having to post a nit-picky comment on a code review ever again!
Install ยท Options ยท CLI ยท API
Badge
Show the world you're using Prettier โ
[](https://github.com/prettier/prettier)
Contributing
See CONTRIBUTING.md.