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-rocket

v11.78.0

Published

Enterprise Grade Linting

Downloads

2

Readme

eslint-config-rocket

"Enterprise Grade Linting"

Philosophy

When coding at scale ensuring high quality code as a project ages can prove difficult. Linting can drastically improve code quality by front loading many of the issues that should be caught in code review to the point where a developer has the most context.

Eslint is a really powerful tool that can do a lot, but there are some things it is better at than others. These configurations aim to focus on what it is good at. Namely improving code quality by making patterns more consistent and encouraging the use of modern language features.

Special Cases

The goal isn't to prevent patterns from being used, but instead to encourage good patterns by default and documenting where patterns need to be broken via required descriptions on disable directives.

If for example I needed to use let for some reason I could do so with the following directive.

// eslint-disable-next-line prefer-const -- This needs to be let
let something = '';

Requiring descriptions like this not only encourages thought about why this pattern is being broken by the developer but by the entire team during code review and future developers coming back to add to and refactor this code.

Having clear descriptions on when linting rules are broken also transparently teaches developers new to the code base what is and is not common practice within the organization

Single Warning Policy

With how powerful eslint is there is a lot of overlap between it and other tools. These configurations intentionally disable any rules that overlap with the functions of a tool that does a better job at enforcing that particular rule.

With how many rules there are across the wide range of plugins this configuration uses there are many that may overlap with each other. Where ever possible these configurations attempt to pick a single rule of those that overlap so that any given problem is only reported once.

Code Formatting

Code formatting is extremely useful when working on a team as it as it reduces the number of changes that aren't meaningful leaving only the important parts for code review. Additionally having consistent formatting makes code much easier to read and switch contexts in the code base.

But, linting works best when it is showing you meaningful warnings and potentially unexpected behavior. Code Formatting rules just increase the noise which which makes more important warnings seem less important.

As such these configurations do not include any code formatting (quote style, indenting, spacing, etc.) rules. There are much better tools out there (prettier) for code formatting so I would encourage you to use those and enable format on save before you consider overriding the eslint configurations with code formatting rules.

Type Checking

Writing JavaScript without Type Checking is like playing web dev on hardcore mode. It is so easy to shoot yourself, or your friend, in the foot. We have many great tools now that luckily make our lives much easier. Chief among them is TypeScript. While ESLint can enforce many type rules, TypeScript does a far better job so any rules that overlap with options or checking already done in TypeScript are intentionally disabled much like code formatting rules and I would encourage you to explore your tsconfig.json options before looking to enable any of those rules.

Usage

  1. Install the configuration

    npm install -D eslint-config-rocket
  2. Add a .eslintrc.js to the root of your project that looks something like this

    module.exports = {
      overrides: [
        {
          extends: [
            'rocket/typescript',
            'rocket/angular',
            'rocket/rxjs',
            'rocket/ngrx',
          ],
          files: '**/*.ts',
          excludedFiles: ['**/*.md.ts', '**/*.spec.ts'],
          parserOptions: { project: './tsconfig.json' },
        },
        {
          extends: ['rocket/typescript', 'rocket/jest'],
          files: '**/*.spec.ts',
          parserOptions: { project: './tsconfig.json' },
          settings: { jest: { version: 26 } },
        },
        {
          extends: ['rocket/angular-template'],
          files: '**/*.html',
          parserOptions: { project: './tsconfig.json' },
        },
        {
          extends: ['rocket/javascript', 'rocket/node'],
          files: '**/*.js',
          excludedFiles: '**/*.md.js',
        },
        {
          extends: ['rocket/markdown'],
          files: ['*.md'],
        },
        {
          extends: [
            'rocket/javascript',
            'rocket/node',
            'rocket/markdown-snippet',
          ],
          files: '*.md.js',
        },
        {
          extends: [
            'rocket/javascript',
            'rocket/angular',
            'rocket/ngneat',
            'rocket/rxjs',
            'rocket/ngrx',
            'rocket/markdown-snippet',
          ],
          files: '*.md.ts',
        },
      ],
      root: true,
    };

    Note: TypeScript rules are not available available in Markdown because while eslint knows how to parse markdown, TypeScript still doesn't.

    You can adjust the configuration to the needs of your project. You may also consider making a configuration for each package if you are using a monorepo to apply the proper platform configurations where they are applicable.

Generator

If you are using an nx workspace you can use the eslint-config-rocket:config to configure your project the the correct eslint extensions.

nx generate eslint-config-rocket:config [projectName] [options,...]

Options:
  --projectName           The name of the project to configure (see workspace.json)
  --language              Wether to use JavaScript or TypeScript
  --framework             The framework this project was written with
  --testing               The testing framework the project uses
  --libraries             A list of libraries that this project consumes

Entry Points

Overview

Each of your extends should consist of either a platform, framework and one or more libraries OR a other-parser.

['<platform>', '<framework>', ...libraries];
// OR
['<other-parser>'];

The supported entry points are

Platforms

  • rocket/javascript
  • rocket/typescript

Frameworks

  • rocket/angular
  • rocket/node
  • rocket/react
  • rocket/react-native

Testing Frameworks

  • rocket/cypress
  • rocket/jest

Utils

  • rocket/lodash
  • rocket/markdown-snippet
  • rocket/ngneat
  • rocket/ngrx
  • rocket/rxjs
  • rocket/storybook

Other Parsers

  • rocket/angular-template
  • rocket/markdown

Rules Overriding

Depending on your project, you may choose to override or add additional rules. To do this simply add a rules with any rules you wish to override under the specific overrides where the rule applies.

Mono repo import sorting

If you wish to sort your can add this rule to your configuration replacing <your-organization> with the namespace of your packages.

{
  "extends": ["rocket/import-order"]
  "rules": {
    "import/order": [
      "warn",
      {
            "alphabetize": {
              "order": "asc",
              "caseInsensitive": false
            },
            "groups": [["external", "builtin"], "internal", "parent", "sibling"],
            "newlines-between": "always",
            "pathGroups": [
              {
                "group": "sibling",
                "pattern": "./*-routing.module",
                "position": "before"
              },
              {
                "group": "external",
                "pattern": "{@<your-organization>/**,}",
                "position": "before"
              },
              {
                "group": "external",
                "pattern": "{@rx-angular/**,@ngrx/**,react-*,@vue/**}",
                "position": "before"
              },
              {
                "group": "external",
                "pattern": "{@angular/**,@nativescript/**,@nestjs/**,react,react-native,vue,@ngneat/spectator,@ngneat/spectator/**}",
                "position": "before"
              }
            ],
            "pathGroupsExcludedImportTypes": ["react"]
      }
    ]
  }
}

Credits

The project structure and original rule set that has been customized and further expanded upon and been provided by eslint-config-intense