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

v1.11.0

Published

[![Dependency Status](https://david-dm.org/dnode/dredis.svg)](https://david-dm.org/dnode/dredis) [![devDependency Status](https://david-dm.org/dnode/dredis/dev-status.svg)](https://david-dm.org/dnode/dredis#info=devDependencies)

Downloads

7

Readme

Dependency Status devDependency Status

Installation

npm i --save dexpress

Add a .eslintrc:

{
  "extends": "dnode"
}

Rules

class-methods-use-this

A method not using this can be static, yes, but I wouldn't force it. There can be reasons a method should be declared used with an instance (non static) independently if the method really use this or not.

comma-dangle

Trailing commas always if multiline. Exception for functions because node doesn't allow it.

consistent-return

A function without a return returns implicit undefined. So if I have one case which returns something and other cases which not, I don't write a return; or return undefined;.

bad

Use return; or return undefined; if nothing should be returned:

function example(example) {
  if (example === 'example') {
    return example;
  }
  return;
}

good

Just skip the unneeded returns and rely on the implicit return undefined:

function example(example) {
  if (example === 'example') {
    return example;
  }
}

global-require

I don't like to force the use of require in a global way. Sometimes its just shorter to use it inside a structure. Like inside an object for the lib.js.

bad

Define first const variables for all require:

const Example = require('./Example');

module.exports = {
  Example,
};

good

Just use require inside the object:

module.exports = {
  Example: require('./Example'),
};

import/newline-after-import

If using require it can be smart to chain and group the require together with other sequences.

bad

Using always new lines to separate require and another sequences:

const app = require('express')();

app.listen(process.env.PORT);

good

Group the lines by logically:

const app = require('express')();
app.listen(process.env.PORT);

import/no-dynamic-require

Dynamic require can not be analysed by static code analyser. But they allow a lot of convenient structures.

bad

Manually require all files statically into an object:

const examples = {
  a: require('./a'),
  b: require('./b'),
  c: require('./c'),
};
const example = 'a';
examples[example]();

good

Use dynamic require for a convenient structure:

const example = 'a';
require(`./${example}`)();

no-await-in-loop

Sometimes the async operations depending on each other in a loop. So its a legal use of await in a loop.

no-console

There isn't something bad in using console.log in node. 12factor say explicit logging should be done by stdout which is console.log.

no-lonely-if

Sometimes there is an else with a following if which is not depending to each other. In this cases its not usefull to transform this into an else if.

no-param-reassign

JavaScript doesn't have overloaded functions. So to define functions which allows multiple type of parameters I think reassign this parameter is a short and effective way to handle this.

bad

Define new variables:

function example(examples) {
  let checkedExamples = examples;
  if (!Array.isArray(checkedExamples)) {
    checkedExamples = [checkedExamples];
  }
}

good

Just reassign the parameters:

function example(examples) {
  if (!Array.isArray(examples)) {
    examples = [examples];
  }
}

no-restricted-syntax

JavaScript allow to iterate over arrays/objects with for ... in and for ... of. I want to use these keywords instead of functions like .forEach because its better readable.

bad

.forEach with arrow function:

examples.forEach(example => {

});

good

Use the native keywords of JavaScript:

for (const example of examples) {
  
}

no-shadow

It can make sense to use the same variables in different layers, especially for closures in array functions. But still care about the readability.

bad

Numerate or prefix variables:

const element = elements.map(element2 => element2.valid)[0];
// or
const element = elements.map(innerElement => innerElement.valid)[0];

good

Use the same variable names if the readability is still given:

const element = elements.map(element => element.valid)[0];

no-underscore-dangle

There is not a problem in using underscores in the beginning of a variable or function, especially if its not used to hint private or protected e.g. in translation function '__()'.