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

requirejs-optional

v0.1.0

Published

A plugin for loading modules optionally in RequireJS.

Downloads

27

Readme

Plugin for RequireJS to load modules optionally. It ensures both non-transitivity and isolation. (Read below for what this means.)

Usage

Using optional!foo means

if foo fails to load in any way do not make it an error but give me {} instead.

Example:

require(["optional!foo"], function (foo) {
  if (foo.something) {
    // Foo was loaded... act accordingly.
  }
  else {
    // Foo was not loaded... act accordingly.
  }
});

Another way to do test whether the module loaded is to inspect the plugin itself. If you require optional!, you get a reference to the plugin. It contains an array of module names. So:

define(["optional!foo", "optional"], function (foo, optional) {
  if (optional.failed.indexOf("foo") !== -1) {
    console.log("failed!");
  }
});

Note that you can also require optional! for optional (the 2nd dependency in the example above) but this syntax may not be supported elsewhere.

A very preliminary version of this plugin returned undefined as the module value for non-existent modules. The problem with this is that this behavior cannot currently be replicated with SystemJS, but one of the goals of this plugin is to have an equivalent for SystemJS that behaves the same way as it does in RequireJS. So we've changed the return value to {} for consistency with SystemJS.

Non-transitivity

Suppose foo depends on bar:

define("foo", ["bar"], function (bar) {
  return {
    foo: bar.something();
  }
});

You load optional!foo. This makes foo is optional, but bar is not optional because it appears as bar, without the plugin. If bar does not exist, then the plugin will kick in and foo will have the value {}. However, bar won't get a value at all. If it is required somewhere else, that's an error. These are sensible semantics.

Some plugins similar to this one are implemented to make optionality transitive. Consider again the case above. With these plugins, setting optional!foo makes foo and all its dependencies individually optional. When bar fails to load, it is considered optional and gets the default value assigned by the plugin to modules that fail to load. foo will then execute its factory function, try to do bar.something() and will fail there.

Isolation

This plugin ensures that calling require(["optional!foo"]) in one location has no effect on other calls where the dependency is on foo, without the plugin.

Some plugins similar to this one will define foo when it fails to load. This breaks isolation. Consider what happens when you use such plugin, when foo does not exist:

  1. Some code requires optional!foo.
  2. Some other code requires foo.

When the first code executes, it gets {} and knows that foo did not exist. All is well. When the 2nd code executes, it gets {}. However, this 2nd code did not use optional! and thus is probably not designed to handle {} as a value. If foo does not exist, it wants failure. Isolation ensures that it gets a failure.