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

breq

v0.2.1

Published

A client-side CommonJS `require` implementation that does NOT require a precompilation build step nor server-side middleware. It instead utilizes synchronous `XMLHttpRequest`s and `eval` instead, which does impose a series of limitations unless you're wil

Downloads

19

Readme

Build Status

breq

"breq" (browser-require) is a client-side CommonJS require implementation that does NOT require a precompilation build step nor server-side middleware. It instead utilizes synchronous XMLHttpRequests and eval instead, which does impose a series of limitations unless you're willing to generate a whole mess of 404s.

Terrible for performance, nice for dynamic ease of use.

Getting Started

Download the production version or the development version.

In your web page:

<script src="dist/breq.min.js"></script>
<script>
  var mod = require("./someCjsModule.js");
</script>

Limitations

Given the browser-based nature of "breq", there are some important limitations to keep in mind that differ from Node's require.resolve lookup algorithms:

  1. It only works over HTTP and HTTPS due to browser security settings for XMLHttpRequest.
  2. It does NOT do any actual "lookups", it only resolves the exact relative path provided.
  3. It currently only supports paths that start with one of the following patterns:
    1. /
    2. ./
    3. ../
  4. It does not support the "any depth" node_modules dynamic lookup for named modules as this would usually result in a series of 404s before it is located.
  5. It does not attempt to append the ".js" extension, etc. to the path provided. As this is made for the web, URI paths are critical and some users will need to consume scripts that do not end with the ".js" extension.
  6. It does not support loading CoffeeScript modules.
  7. It does not currently support loading JSON "modules".

Roadmap Brainstorming

Some ideas for future exploration in "breq":

  1. Add support for JSON "modules".
  2. Add a configuration object.
  3. Allow consumers to configure a "module root" [with either a method like setModuleRoot or a config property like require.paths] where we can seek out named modules, e.g.

require.setModuleRoot("/node_modules/"); var mod = require("myCjsModule"); // path will [first] resolve to "/node_modules/myCjsModule/index.js"


 4. Allow consumers to set a configuration option that _does_ enable the actual Node-style lookup
    algorithm, keeping in mind that this setup will likely produce an exceptionally large quantity
    of `404`s. This would also include auto-appending the ".js" extension during some of the lookup
    attempts if it is not already present, e.g.
     ```js
var mod = require("./myCjsModule");  // path will resolve to "./myCjsModule.js"