Skip to content
/ sherif Public

Opinionated, zero-config linter for JavaScript monorepos

License

Notifications You must be signed in to change notification settings

QuiiBz/sherif

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

83 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation


Sherif: Opinionated, zero-config linter for JavaScript monorepos


Cover

About

Sherif is an opinionated, zero-config linter for JavaScript monorepos. It runs fast in any monorepo and enforces rules to provide a better, standardized DX.

Features

  • PNPM, NPM, Yarn...: sherif works with all package managers
  • 🔎 Zero-config: it just works and prevents regressions
  • Fast: doesn't need node_modules installed, written in 🦀 Rust

Installation

Run sherif in the root of your monorepo to list the found issues. Any error will cause Sherif to exit with a code 1:

# PNPM
pnpm dlx sherif@latest
# NPM
npx sherif@latest

We recommend running Sherif in your CI once all errors are fixed. Run it by specifying a version instead of latest. This is useful to prevent regressions (e.g. when adding a library to a package but forgetting to update the version in other packages of the monorepo).

GitHub Actions example
name: Sherif
on:
  pull_request:
jobs:
  check:
    name: Run Sherif
    runs-on: ubuntu-22.04
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - uses: actions/setup-node@v3
        with:
          node-version: 20
      - run: npx [email protected]

Autofix

Most issues can be automatically fixed by using the --fix (or -f) flag. Sherif will automatically run your package manager's install command (see No-install mode to disable this behavior) to update the lockfile. Note that autofix is disabled in CI environments (when $CI is set):

sherif --fix

No-install mode

If you don't want Sherif to run your packager manager's install command after running autofix, you can use the --no-install flag:

sherif --fix --no-install

Rules

You can ignore a specific rule by using --ignore-rule <name> (or -r <name>):

# Ignore both rules
sherif -r packages-without-package-json -r root-package-manager-field

You can ignore all issues in a package by using --ignore-package <pathOrName> (or -p <pathOrName>):

# Ignore all issues in the `@repo/tools` package
sherif -p @repo/tools
# Ignore all issues for packages inside `./integrations/*`
sherif -p "./integrations/*"

Note Sherif doesn't have many rules for now, but will likely have more in the future (along with more features).

empty-dependencies

package.json files should not have empty dependencies fields.

multiple-dependency-versions

A given dependency should use the same version across the monorepo.

You can ignore this rule for a specific dependency and version or all versions of a dependency if it's expected in your monorepo by using --ignore-dependency <name@version> / --ignore-dependency <name> (or -i <name@version> / -i <name>):

# Ignore only the specific dependency version mismatch
sherif -i [email protected] -i [email protected]

# Completely ignore all versions mismatch of these dependencies
sherif -i react -i next

non-existant-packages ⚠️

All paths defined in the workspace (the root package.json' workspaces field or pnpm-workspace.yaml) should match at least one package.

packages-without-package-json ⚠️

All packages matching the workspace (the root package.json' workspaces field or pnpm-workspace.yaml) should have a package.json file.

root-package-dependencies ⚠️

The root package.json is private, so making a distinction between dependencies and devDependencies is useless - only use devDependencies.

root-package-manager-field

The root package.json should specify the package manager and version to use. Useful for tools like corepack.

root-package-private-field

The root package.json should be private to prevent accidentaly publishing it to a registry.

types-in-dependencies

Private packages shouldn't have @types/* in dependencies, since they don't need it at runtime. Move them to devDependencies.

unordered-dependencies

Dependencies should be ordered alphabetically to prevent complex diffs when installing a new dependency via a package manager.

Credits

Sponsors

Sponsors

License

MIT