Don't disable unicorn/no-null?

[justinhelmer]

Background
I like your position on not using null (in favor of undefined).

This library does two things:

1. Adds a @typescript-eslint/ban-types rule that disables the use of the null type.
2. Turns off the unicorn/no-null rule in favor of @typescript-eslint/ban-types.

For a little more background, we were led to your xo and xo-typescript configurations by using npm init @eslint/config from ESLint's Getting Started (and we love it). I stumbled on the rule of disallowing the null type by accident, read your discussion, and fully bought in.

Problem
The problem is, that @typescript-eslint/ban-types will not match value usages, by design. However, the unicorn/no-null rule specifically disallows the use of the null literal:

// will yell
const param: null = null;

// will not yell
const param = null;

Since we want to use type inference as much as possible, the current @typescript-eslint/ban-types rule in this library probably won't catch much for us - we need the value checks.

Suggestion

1. Don't disable the unicorn/no-null rule since it complements the @typescript-eslint/ban-types rule (one checks literals, one checks types).
2. Make this behavior the default when using npm init @eslint/config (maybe include eslint-plugin-unicorn?) - I realize this would be a separate PR in a separate repo.

For (1), we currently have the following config in the meantime (reduced to only show the important bits):

module.exports = {
  extends: [
    'plugin:unicorn/recommended',
    'xo',
    'xo-typescript'
  ],
  rules: {
    'unicorn/no-null': 'error',
  },
};

For (2), you will probably tell us to just use XO directly instead of juggling the extends ourselves.

WDYT?