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

@flagbit/tslint-config

v2.0.4

Published

## How to use

Downloads

2

Readme

flagbit tslint config

How to use

Install the package inside your project...

yarn add @flagbit/tslint-config

...and add a tslint.json containing this:

{
  "extends": "@flagbit/tslint-config"
}

Which rules get applied?

Our tslint rules are pretty much the same as in a regular @angular/cli project, but with a twist:

completed-docs

Everything needs to be documented! A good example of well documented code can be found here:

HooksService

A minimal example would be something like this:

/**
 * ExampleComponent
 * ================
 *
 * This component is used to demostrate how our code should look like.
 */
export class ExampleComponent {
  /**
   * We are storing something inside this property
   */
  private _something = false;

  /**
   * The description of this method
   * @param param The parameter that is getting passed
   */
  public someMethod(param: number): boolean {
    if (param) {
      return true;
    }

    return this._something;
  }
}

member-access

This rule is making sure that every class-member needs defined access. Please keep in mind that during your unit-tests you can only access the public properties!

Example

Bad:

export class ExampleComponent {
  someMethod(): boolean {
    // ...
  }
}

Good:

export class ExampleComponent {
  public someMethod(): boolean {
    // ...
  }
}

newline-before-return

This is making your code more readable. Forcing a newline before return, if there is more than one line in your method.

Example

Bad:

export class ExampleComponent {
  // ...
  public somePublicMethod(paramOne: boolean, paramTwo: boolean): boolean {
    if (paramOne) {
      return paramTwo;
    }
    return paramOne;
  }
}

Good:

export class ExampleComponent {
  // ...
  public somePublicMethod(paramOne: boolean, paramTwo: boolean): boolean {
    if (paramOne) {
      return paramTwo;
    }

    return paramOne;
  }

  /**
   * If the return is the ONLY line, you shouldn't add the emptyline
   */
  public someOtherPublicMethod(): boolean {
    return this._property;
  }
}

no-irregular-whitespace

This is making your code more readable, as it forbids to many empty lines, where they aren't necessary.

one-variable-per-declaration

This is making your code more readable, by throwing an error if you are defining more than one variable per declaration block.

Example

This is bad, because you don't see in first sight if you are declaring or re-declaring:

const one = 'one',
  two = 'two',
  three = 'three';

This is more readable:

const one = 'one';
const two = 'two';
const three = 'three';

typedef

We are forcing, that parameters and call-signatures always have a typedef. This is leading to easier editing and/or extending, as you always know what the methods need as input, and what they give back.

Example

Bad:

export class ExampleComponent {
  // ...
  public somePublicMethod(paramOne, paramTwo) {
    if (paramOne) {
      return paramTwo;
    }

    return paramOne;
  }
}

Good:

export class ExampleComponent {
  // ...
  public somePublicMethod(paramOne: boolean, paramTwo: boolean): boolean {
    if (paramOne) {
      return paramTwo;
    }

    return paramOne;
  }
}

variable-name

We are forcing proper variable-names, to have cleaner code. variables have to be in camelCase or UPPERCASE, to see directly if one is a variable or a class or whatever. Also leading underscores are allowed, to name private properties in classes. The UPPERCASE is forcing us to use const

Example

Bad:

const Some_VariAble = 'something';

Good:

let someVariable = 'something';
const SOMEVARIABLE = 'something';

export class ExampleComponent {
  private _property: boolean;

  public somePublicMethod(): boolean {
    return this._property;
  }
}

no-unused-css

We make sure that we don't have css inside our stylesheets that isn't used inside the component.

template-i18n

We make sure that everytime an i18n directive is used inside the templates, we also added an i18n-id. This is making your translation-files way more readable.

Example

Bad:

<p>Component Works!</p>
<p i18n>Component Works!</p>

Good:

<p i18n="@@componentWorksMessage">Component Works!</p>

use-component-view-encapsulation

We are forcing that we never use ViewEncapsulation.None in components. This way we are minimizing the risk of breaking styles outside of the component we're working on.

prefer-on-push-component-change-detection

We are forcing ChangeDetection.OnPush in components. With this we are minimizing the risk of a poor performance by too deep and heavy ChangeDetection loops.

template-use-track-by-function

We can help Angular to track which items added or removed by providing a trackBy function. The trackBy function takes the index and the current item as arguments and needs to return the unique identifier for this item.

Its always a good idea to use a trackBy function in *ngFor. With this rule we make sure that every template-loop is using one!

Example

Bad:

<li *ngFor="let product of products">
  <!-- ... -->
</li>

Good:

export class ListProductsComponent {
  // ...
  public trackByFn(index: number, item: IProduct): string {
    return item.id;
  }
}
<li *ngFor="let product of products;trackBy: trackByFn">
  <!-- ... -->
</li>