npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

eslint-config-obey-ziga

v3.2.15

Published

Ziga's very opinionated JS ESLint base config.

Downloads

12

Readme

Obey Ziga

This package provides heavily opinionated rules, in a shared config.

The idea for the package name branched out from an internal joke at my office. I hold strong opinions about writing code, and my teammates were indifferent. So it became a running joke to just "obey what Ziga says."

obey-ziga aims to make your code make more sense to your future self and its future readers.

Installation

$ npm i -D eslint-config-obey-ziga

With React

$ npm i -D eslint-plugin-jsx-a11y eslint-plugin-react eslint-plugin-react-hooks

With TypeScript

$ npm i -D @typescript-eslint/parser @typescript-eslint/eslint-plugin

Usage

Once the package is installed, add obey-ziga to your extends prop in either package.json or .eslintrc.*.

{
  "extends": [
    "eslint:all",
    "obey-ziga"
  ]
}

With React

{
  "extends": [
    // ...
    "plugin:react/all",
    "plugin:jsx-a11y/recommended",
    "obey-ziga/react"
  ]
}

NB: plugin:react-hooks/recommended is actively excluded as it only has two rules which are both set to "error" by obey-ziga/react.

With TypeScript

{
  "extends": [
    // ...
  ],
  "parser": "@typescript-eslint/parser",
  "overrides": [
    {
      "files": ["*.ts", "*.tsx"],
      "extends": [
        "plugin:@typescript-eslint/all",
        "obey-ziga/typescript"
      ],
      "parserOptions": {
        "project": [
          "./tsconfig.json"
        ]
      }
    }
  ]
}

Philosophy

Even though you might be indifferent about some rules, there are things that are worth being assisted in remembering.

I would rather explicitly take a position on a rule than leave it potentially undecided.

As a default, I recommend you turn on eslint:all in your linting, and let this config explicitly disable or modify rules. The recommendation also applies for plugin:react/all, plugin:jsx-a11y/recommended, and plugin:@typescript-eslint/all.

Warning equals error

It is a hot topic in the dev world whether to treat warnings as errors or just something that can be safely ignored.

This package is on the side of "treat warnings as errors". Only no-warning-comments (e.g. // TODO, // FIX) will yield warnings. Everything else will yield errors.

Rather explicitly disable rules case-by-case than be just warned and have an option to ignore it.

TODO, FIX, etc. comments

obey-ziga warns about these rather than yield errors because I recognize that development is a complex thing, and some logic requirements can be extensive, so you implement them in stages.

obey-ziga warns rather than leave this rule off to make sure these type of comments are not forgotten as is usually the case.