.eslintrc.json

{
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaVersion": 2018, // Allows for the parsing of modern ECMAScript features
        "sourceType": "module", // Allows for the use of imports
        "project": [ "./tsconfig.eslint.json" ]
    },
    "extends": [
        "eslint:recommended",
        "plugin:@typescript-eslint/recommended",
        "plugin:@typescript-eslint/recommended-requiring-type-checking",
        "plugin:import/errors",
        "plugin:import/warnings",
        "plugin:import/typescript"
    ],
    "plugins": ["@typescript-eslint", "import"],
    "reportUnusedDisableDirectives": true,
    "env": {
        "node": true
    },
    "ignorePatterns": ["*/node_modules/**/*", "*/dist/**/*", "*/build/**/*", "packages/*/dist/**/*", "packages/*/build/**/*", "models/*/**/*", "**/forwards/**/*"],
    "rules": {
        "@typescript-eslint/no-explicit-any": "off",
        "@typescript-eslint/ban-types": [
            "error",
            {
                "types": {
                    "{}": false
                },
                "extendDefaults": true
            }
        ],
        // turn on errors for missing imports
        "import/no-unresolved": "error",

        "@typescript-eslint/require-await": "off",

        // We can turn these on from time to time but in general they rules
        // make our lives harder instead of easier
        "@typescript-eslint/no-unsafe-argument": "off",
        "@typescript-eslint/no-unsafe-assignment": "off",
        "@typescript-eslint/no-unsafe-member-access": "off",
        "@typescript-eslint/no-unsafe-return": "off",
        "@typescript-eslint/no-unsafe-call": "off",
        "@typescript-eslint/restrict-template-expressions": "off",
        "@typescript-eslint/no-base-to-string": "off",

        "no-constant-condition": [
            "error",
            {
                "checkLoops": false
            }
        ],

        "no-restricted-imports": [
            "error",
            {
                "patterns": [
                    {
                        "group": ["**/export"],
                        "message": "Please import the directory rather than the export file"
                    },

                    {
                        "group": ["**/export.js"],
                        "message": "Please import directly from the defining file"
                    }
                ]
            }
        ],

        // Namespaces are the only way to nest types and merge with some declarations.  IOW they have uses beyond simple
        // package structure which error verbiage indicates is the purpose of the test
        "@typescript-eslint/no-namespace": "off",

        // Cannot nest functions within namespaces with this on
        "no-inner-declarations": "off",

        // Blocks are the only way to have case-specific variables defined. Alternative is a bunch of lets for all
        // possible variables for all cases above the switch.  Which sucks
        "no-case-declarations": "off",

        // Metaprogramming is impossible with this on
        "@typescript-eslint/no-implied-eval": "off",

        // I mean, I understand why this rule exists, but sometimes you need to assign "this" to a variable (see e.g. cd
        // method in github.ts)
        "@typescript-eslint/no-this-alias": "off",

        // This prevents us from transpiling to ESM that works in both node and the browser for some CommonJS
        // dependencies (elliptic and ansi-colors are two examples)
        "import/default": "off",

        // TS I believe takes care of this for us, and the plugin does not understand TS object/namespace merges
        "import/export": "off",

        // Related to import/default, this generates warnings when we use properties of the default export when eslint
        // thinks we should be using the named export.  In some cases it isn't even possible to do it the way eslint
        // wants us to (e.g. you can't do "import { static } from express because "static" is a reserved word.).  In
        // other cases the code is valid but the transpiled ESM isn't compatible with Node because it's not smart enough
        // to find the "named exports" in CommonJS files
        "import/no-named-as-default-member": "off",

        // This makes it impossible to compare non-enums to enums, like one might do with a value off the wire
        "@typescript-eslint/no-unsafe-enum-comparison": "off",

        // tsc catches these for us and eslint doesn't recognize references to type imports in comment @links
        "@typescript-eslint/no-unused-vars": "off",

        // This is highly inconvenient and breaks basic language features.  I don't think we've ever actually unbound
        // a method unintentionally and we do it quite often intentionally.  Perhaps its useful if you aren't authoring
        // a library
        "@typescript-eslint/unbound-method": "off",

        // Umm, this mattered for IE <= 8??
        "no-ex-assign": "off",

        // Always of dubious value, this rule is buggy as of typescript-eslint 7.2.0 and TS 5.4.2 (works w/ TS 5.3.3
        // though)
        "@typescript-eslint/no-redundant-type-constituents": "off",

        // This rule is fine...  Except it's redundant with tsc and seems to be buggy with wildcard package.json
        // import aliases
        "import/no-unresolved": "off"
    },
    "settings": {
        "import/extensions": [".ts"],
        "import/parsers": {
            "@typescript-eslint/parser": [".ts"]
        },
        "import/resolver": {
            "typescript": {
                // Multiple tsconfigs (Useful for monorepos)
                "project": "packages/*/tsconfig.json"
            }
        }
    }
}