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

jsgreat

v0.2.0-dev.1

Published

Yola's guide to writing JS great.

Downloads

443

Readme

jsgreat

npm version

Our JavaScript code will (mostly) follow the Google JavaScript Style Guide. A few slight variations and additions are laid out below. There will also be exceptions to these rules in some existing code, but where possible, existing code should be updated as it is edited to conform to the style guide.

Many of these options will be enforced by this .jshintrc file. This file can be used by tools that support JSHint integration. For most projects, it is strongly recommended to use Grunt and the grunt-contrib-jshint plugin to run jshint.

The following additions and variations will be enforced:

Strings

The guide prefers ' over ". We only require that quotes are used consistently within the file. This will be enforced by jshint.

Indentation

Prefer 2-space indentation for all Javascript and JSON files.

Multiple Vars

Prefer multiple var statements, each on their own line, for any variables that have assignments. Multiple variables without assignments can be vared together on a single line.

Don't do this:

var foo = 'foo',
  bar = 'bar',
  baz = 'baz';

Do this instead:

var foo = 'foo';
var bar = 'bar';
var baz = 'baz';

This is okay, too:

var foo, bar, baz;

Function Declarations vs. Function Expressions

Prefer vared function expressions over function declarations.

Don't do this:

function() {
   function foo() { ... };
}();

Do this instead:

function() {
  var foo = function() { ... };
}();

Aligning Assignments

Variable assignments should not be aligned by value. Don't do this:

var foo      = 'foo';
var bar      = 'bar';
var fizzbuzz = 'fizzbuzz';

var obj = {
  foo     : 'foo',
  bar     : 'bar',
  fizzbuzz: 'fizzbuzz'
};

Do this instead:

var foo = 'foo';
var bar = 'bar';
var fizzbuzz = 'fizzbuzz';

var obj = {
  foo: 'foo',
  bar: 'bar',
  fizzbuzz: 'fizzbuzz'
};

Anonymous Callback Functions

Prefer vared function expressions over anonymous functions for callbacks where it makes sense.

Don't do this:

$('.someElement').click(function(){
  console.log('It was clicked!');
});

Do this instead:

var logItWasClicked = function(){
  console.log('It was clicked!');
});
$('.someElement').click(logItWasClicked);

This is especially important in newed objects like Backbone Models and Views, where scope is important, and callbacks often reference other properties on the instance.

Manipulating this context

Prefer calling functions in the required scope vs. saving this in a that or self variable.

Don't do this:

// Code that needs access to local variables and `this` in an anonymous callback
var MyModule = {
  message: 'Hello World!',
  doGetAndCallback: function(callback){
    var that = this;
    $.get('some/ajax/request', function(){
      callback(that.message);
    });
  }
};

Do either of these instead:

// Save just the info you need
var MyModule = {
  message: 'Hello World!',
  doGetAndCallback: function(callback){
    var message = this.message;
    $.get('some/ajax/request', function(){
      callback(message);
    });
  }
};

// Change the scope to make sure it is called in the proper context
var MyModule = {
  message: 'Hello World!',
  doGetAndCallback: function(callback){
    $.get('some/ajax/request', _.bind(function(){
      callback(this.message);
    }, this));
  }
};

Or, better yet, return a Deferred/Promise, and let the caller setup the callback on their end:

var MyModule={
  message: 'Hello World!',
  doGet: function(){
    return $.get('some/ajax/request');
  }
};

Curly Braces

Curly braces are required around blocks in loops and conditionals. This is enforced by jshint.

Don't do this:

if(foo)
  console.log('bar');

Do this instead:

if(foo){
  console.log('bar');
}

Strict Mode

All modules should be wrapped in IIFEs or RequireJS CommonJS define calls, and use strict mode. This will be enforced by JSHint

(function(){
  'strict mode';
  //Code goes here
})();

Or

define(function(require, exports, module)){
  'strict mode';
  //code goes here
});

Unused Variables

Unused variables should be removed from the code when they are no longer needed. This will be enforced by jshint.

Because some libraries expect function arguments with specific names and signatures, function parameters that are not used will not be ignored.

Don't do this:

var x;  //x is never used

But this is okay:

define(function(require, exports, module){
  //module is never used
});

Coerced Types and Equality

Prefer === over ==. This will be enforced by JShint.

However, there is an exception for null comparisons. i.e. == null is acceptable.

Undefined Variables

All variables must be explicitly defined. This option will be enforced by JSHint.

This is a simple way to catch mistyped variable names and copy/paste errors, but it also helps to prevent over-dependence on the global namespace, and forces modules to be more explicit about their dependencies.

One specific example of why this can be important is in Backbone views, which use a scoped $ function to find elements inside the view. If you accidentally use the global $('.selector') instead of this.$('.selector'), you're searching the full DOM instead of just your view.

Using Variables Before Definition

Variables must be defined earlier in the code than they are used. (Hoisting makes it possible to accidentally use a variable before it's defined.) This will be enforced by JSHint.

Trailing Whitespace

Lines shouldn't have whitespace at the end. We've always enforced this. Now JSHint will enforce it.

80 Column Limit

Although the style guide isn't fully explicit about it, lines should not exceed 80 characters.