Add `unopinionated` preset

I propose turning off the following rules by default, so that the recommended config could act as a baseline which may be extended explicitly:

• unicorn/filename-case – This goes against the principle set by one of the most popular linting packages, eslint-config-airbnb. See this excerpt from their style guide:

  23.6 A base filename should exactly match the name of its default export.

• unicorn/no-nested-ternary – Doesn’t work properly when used along with Prettier, as formatting removes parentheses used in ternary expressions.

• unicorn/no-null – This is very opinionated and external libraries like React and Prisma depend on null. Also, something == null checks for both null and undefined at once, so it’s less prone to errors in comparison to something === undefined || something === null.

• unicorn/no-useless-undefined – Conflicts with ESLint’s built-in consistent-return rule, which is enforced by Airbnb’s config. Causes all of the following code to be invalid:

  function fetchModel() {
    if (exists) return { something: "some data" };
    return undefined; // As embraced by `unicorn/no-null`
  }
  
  function fetchModel() {
    if (exists) return { something: "some data" };
    return; // Violates `consistent-return`, even when omitted 
  }
  

• unicorn/prefer-query-selector – The alternatives, namely getElementById and getElementsByClassName, offer better performance. Selector-based queries should be avoided in general, even in CSS, as they get complex pretty fast. Using IDs and class names for locating elements is a well-tested practice, while complex selectors are questionable.

• unicorn/prevent-abbreviations – While the intent is great, way too many false positives may occur. For instance, React uses the term props to identify attributes passed to a JSX element. They aren’t widely called properties in the documentation and tutorials. Same goes for the req and res parameters of an API handler function, as popularized by Express.

As an alternative, a recommended-loose or recommended-unopinionated config may also be added to avoid the issues outline above. My goal is to set up ESLint with a strict set of rules as simple as below:

{
  "root": true,
  "parserOptions": { "project": "./tsconfig.json" },
  "extends": [
    "airbnb-typescript",
    "airbnb/hooks",
    "plugin:@typescript-eslint/recommended",
    "plugin:unicorn/recommended",
    "prettier",
    "prettier/@typescript-eslint",
    "prettier/react",
    "prettier/unicorn"
  ]
}

[sindresorhus]

Isn’t every rule potentially “opinionated”?

No. Some rules are about correctness or preventing bugs. I don’t consider that opinionated. I also wouldn’t consider rules that enforce using more modern APIs opinionated.

For example, no-instanceof-array is about correctness, but no-array-reduce is opinionated.

Or, if worth having in this package, perhaps it should explicitly mention airbnb: plugin:unicorn/airbnb

I don’t see why it should have the name of a random ESLint config. unopinionated is perfectly clear.

[kripod]

I would highly appreciate a separate unopinionated or loose config if that’s a possibility. Thanks for taking your time to read and review my suggestions! 🙏