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

defuse

v0.3.1

Published

A poor man's module namespacing solution for the browser

Downloads

24

Readme

defuse

A poor man's module namespacing solution for the browser.

defuse.def('foo.bar', function(exports) {
    exports.baz = function() { return 'qux'; }
});

console.log(defuse.use('foo.bar').baz());

Why?

For simple projects, I sometimes don't need the power offered by module loaders, bundlers or similar tools, and would prefer to just have a way of namespacing the project's modules, as opposed to a complete solution for requireing and using everything, vendor libraries included.

Browserify is really awesome, my only reason for not using it for every browser-based project is that I have yet to find a nice way of testing browserified projects using phantomjs. For projects that don't use the DOM, or projects which make sense both in node and the browser, browserify is perfect. The tests can be done from node, and each module to be tested can simply be required. Things aren't as simple when phantomjs is involved. Short of writing a very awkward require utility available in the tests, we need to test each module using the entire browserified bundle. This makes writing tests a bit more difficult, since the stack traces are less useful than if the modules were still separate files.

There are several namespacing patterns commonly used in browser-based projects that are simple enough to use without needing to bring in yet another library. For example:

// thing.js
(function(exports) { ... })(window.thing = {});

// subthing.js
(function(exports) { ... })(window.thing.subthing = {});

The problem with simply using those patterns is that you end up needing to add each new script to the list of scripts to be concatenated in your Gruntfile/makefile/whatever you use. Simply using a glob pattern like *.js is out of the question, since ordering matters (for eg, subthing.js uses things defined in thing.js, so it needs to appear after thing.js). This isn't a major problem, so most people just live with it. What I really wanted was to avoid implicit dependencies amongst scripts (one of the things AMD solves), but boilerplate-free and as simple to use as CommonJS. defuse is my attempt at this, by only loading a module when you use it for the first time, as opposed to when it is defined (lazy loading), but in a way that feels (to me) closer to CommonJS.

API

defuse.def(name, loader)

Defines a module.

defuse.def('foo.bar', function(exports) {
    exports.baz = function() { return 'qux'; }
});

defuse.use(name)

Returns the exports of a defined module.

console.log(defuse.use('foo.bar').baz());

defuse.undef(name)

Undefines a module.

defuse.undef('foo.bar');

defuse.pollute()

Assigns defuse's api methods to the global namespace. Excludes itself, unpollute and exports. If you would like these methods available globally out of the box, use the defuse-global.js or defuse-global.min.js builds.

defuse.pollute();

// we can now do this:
def('foo.bar', function() { ... });
use('foo.bar');

defuse.unpollute()

Restore properties the global object had and remove properties that the global object did not have before pollute.

def = 'tones'

defuse.pollute();
def('foo.bar', function() { ... });

defuse.unpollute();
console.log(def);
// => 'tones'

defuse.exports()

Returns a shallow copy of the defuse api. Useful for mixing in. Excludes itself, pollute and unpollute.

_.mixin(defuse.exports());

// we can now do this:
_.def('foo.bar', function() { ... });
_.use('foo.bar');