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 🙏

© 2025 – Pkg Stats / Ryan Hefner

eslint-plugin-extjs

v0.0.3

Published

ESLint rules for projects using the ExtJS framework.

Readme

eslint-plugin-extjs

npm Travis Gemnasium

ESLint rules for projects using the ExtJS framework. These rules are targeted for use with ExtJS 4.x. Pull requests for compatibility with 5.x are welcome!

Rule Details

ext-array-foreach

The two main array iterator functions provided by ExtJS, Ext.Array.forEach and Ext.Array.each, differ in that each provides extra functionality for early termination and reverse iteration. The forEach method, however, will delegate to the browser's native Array.forEach implementation where available, for performance. So, in situations where the extra features of each are not needed, forEach should be preferred. As the forEach documentation says:

[Ext.Array.forEach] will simply delegate to the native Array.prototype.forEach method if supported. It doesn't support stopping the iteration by returning false in the callback function like each. However, performance could be much better in modern browsers comparing with each.

The following patterns are considered warnings:

Ext.Array.each(
    ['a', 'b'],
    function() {
        // do something
    }
);

Ext.Array.each(
    ['a', 'b'],
    function() {
        // do something
    },
    this,
    false
);

The following patterns are not considered warnings:

Ext.Array.forEach(
    ['a', 'b'],
    function() {
        // do something
    }
);

Ext.Array.each(
    ['a', 'b'],
    function(item) {
        if (item === 'a') {
            return false;
        }
    }
);

Ext.Array.each(
    ['a', 'b'],
    function() {
        // do something
    },
    this,
    true
);

ext-deps

One problem with larger ExtJS projects is keeping the uses and requires configs for a class synchronized as its body changes over time and dependencies are added and removed. This rule checks that all external references within a particular class have a corresponding entry in the uses or requires config, and that there are no extraneous dependencies listed in the class configuration that are not referenced in the class body.

The following patterns are considered warnings:

Ext.define('App', {
    requires: ['Ext.panel.Panel']
});

Ext.define('App', {
    constructor: function() {
        this.panel = new Ext.panel.Panel();
    }
});

The following patterns are not considered warnings:

Ext.define('App', {
    requires: ['Ext.panel.Panel'],
    
    constructor: function() {
        this.panel = new Ext.panel.Panel();
    }
});

Ext.define('App', {
    extend: 'Ext.panel.Panel'
});

no-ext-create

While using Ext.create for instantiation has some benefits during development, mainly synchronous loading of missing classes, it remains slower than the new operator due to its extra overhead. For projects with properly configured uses and requires blocks, the extra features of Ext.create are not needed, so the new keyword should be preferred in cases where the class name is static. This is confirmed by Sencha employees, one of whom has said:

'Ext.create' is slower than 'new'. Its chief benefit is for situations where the class name is a dynamic value and 'new' is not an option. As long as the 'requires' declarations are correct, the overhead of 'Ext.create' is simply not needed.

The following patterns are considered warnings:

var panel = Ext.create('Ext.util.Something', {
    someConfig: true
});

The following patterns are not considered warnings:

var panel = new Ext.util.Something({
    someConfig: true
});

var panel = Ext.create(getDynamicClassName(), {
    config: true
});

no-ext-multi-def

Best practices for ExtJS 4 dictate that each class definition be placed in its own file, and that the filename should correspond to the class being defined therein. This rule checks that there is no more than one top-level class definition included per file.

The following patterns are considered warnings:

// all in one file
Ext.define('App.First', {
    // ...
});
Ext.define('App.Second', {
    // ...
});

The following patterns are not considered warnings:

// file a
Ext.define('App', {
    // class definition
});

// file b
Ext.define('App', {
    dynamicDefine: function() {
        Ext.define('Dynamic' + Ext.id(), {
            // class definition
        });
    }
});