🚨 Shai-Hulud Strikes Again:834 Packages Compromised.Technical Analysis →
Socket
Book a DemoInstallSign in
Socket

@aparajita/eslint-config-base

Package Overview
Dependencies
Maintainers
1
Versions
8
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

@aparajita/eslint-config-base

My crazy eslint rules for JavaScript + TypeScript

latest
Source
npmnpm
Version
1.1.6
Version published
Maintainers
1
Created
Source

@aparajita/eslint-config-base

This config for JavaScript/TypeScript contains an extremely complete (and quite strict) set of rules that maximizes type safety and automatic formatting of source code. It was created to make sharing between my projects much easier, and to have a single source of truth for my eslint config. You may find it useful as well.

Installation

% pnpm add -D @aparajita/eslint-config-base

This config has several peer dependencies which you may need to install as devDependencies as well:

{
  "devDependencies": {
    "@typescript-eslint/eslint-plugin": "^5.29.0",
    "@typescript-eslint/parser": "^5.29.0",
    "eslint": "^8.18.0",
    "eslint-config-prettier": "^8.5.0",
    "eslint-config-standard": "^17.0.0",
    "eslint-import-resolver-typescript": "^3.1.1",
    "eslint-plugin-import": "^2.26.0",
    "eslint-plugin-n": "^15.2.3",
    "eslint-plugin-promise": "^6.0.0",
    "typescript": "^4.7.4"
  }
}
% pnpm add -D \
eslint typescript \
@typescript-eslint/eslint-plugin \
@typescript-eslint/parser \
eslint-config-prettier \
eslint-config-standard \
eslint-import-resolver-typescript \
eslint-plugin-import \
eslint-plugin-n \
eslint-plugin-promise

Usage

In order to use this config, add it to the extends clause of your eslint config.

module.exports = {
  extends: ['@aparajita/base'],
}

If you are linting TypeScript, the @typescript-eslint plugin used by this config needs to know the directory where your root tsconfig is and its name. By default, these are set to process.cwd() and process.cwd()/tsconfig.json respectively.

If your root tsconfig is not in the directory from which eslint will be run, add the following to the eslint config of your project.

const path = require('path')

// Set this however you want: relative, absolute, calculated, whatever
const rootTsconfigPath = path.resolve('/path/to/root/tsconfig.json')

module.exports = {
  extends: ['@aparajita/base'],

  overrides: [
    {
      files: ['*.ts', '*.tsx'],
      parserOptions: {
        tsconfigRootDir: path.dirname(rootTsconfigPath),
        project: [rootTsconfigPath],
      },
    },
  ],
}

If your project builds multiple products with separate tsconfig files, you will need to tell this config about it. For example, let’s say you are building a CLI tool with a separate tsconfig in addition to something else. Here’s how you might do it.

module.exports = {
  extends: ['@aparajita/base'],
  overrides: [
    {
      files: ['./cli/make-ios-plugin.ts'],
      parserOptions: {
        tsconfigRootDir: '.',
        project: './tsconfig-cli.json',
      },
    },
  ],
}

Caching

Some of the TypeScript rules in this config require the linter to parse your TypeScript files. This can affect performance. Therefore, it is recommended that you use the --cache option with eslint so that each lint run will only lint files that have changed. Be sure to add the cache file to .gitignore!

Coding style

In terms of coding style, this config follows standard js with the exception of disallowing a space after function name declarations (space-before-function-paren).

Any formatting rules that Prettier handles are not enforced by this config. I have found I can avoid a lot of problems by configuring and running prettier separately from eslint. As the prettier authors point out about integrating prettier with eslint:

You end up with a lot of red squiggly lines in your editor, which gets annoying. Prettier is supposed to make you forget about formatting – and not be in your face about it!

Rule philosophy

The TypeScript rules in this config are extremely strict, to prevent casual subverting of the type system. TypeScript and the @typescript-eslint rules are trying to prevent us from introducing subtle runtime errors, so my philosophy is that you should have to explicitly disable such rules, because that makes you think twice about whether it’s really safe to do so.

You can of course override any of the rules in this config to suit your own tastes.

Keywords

eslint

FAQs

Package last updated on 30 Sep 2023

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts