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

require_everywhere

v1.0.0

Published

Consistent asynchronous require support for Node, Browsgit er main threads, and WebWorkers.

Downloads

1

Readme

require_everywhere

Did you ever want to use the same module code in more than 1 environment in your application? That's what this package offers. You get to write your modules once with no weird ifs and complications to muck things up. What's the cost? Just 2 extra lines of code per module, and 1 additional line in the main application file.

Usage

The initiating .html file needs to load require_web with a <script> tag. This must be loaded before the first .js module calls require. Node and WebWorker code just needs to load the appropriate "require_xxx.js" before trying to use it. Unless you intend to use the returned Promise objects directly, it's best to put all of your logic in the main module in an asynchronous IIFE.

Initializing Code

The Browser Main Thread case...

<!doctype HTML>
<html>
    <head>
        ...
        <script type="javascript" src="path/to/require_web.js"></script>
        <script type="javascript" src="path/to/your/js/module"></script>
        ...
    </head>
    <body>
        ...
    </body>
</html>

The WebWorker case...

importScripts("path/to/require_web.js");
(async ()=>{
    //Your module code here
})();

The NodeJS case...

require = require("path/to/require_node.js");
(async ()=>{
    //Your module code here
})();

Module Code

After that, all that's left is to load what you need and get running. There's 2 approaches to it, but they both do essentially the same thing.

If you're just loading a single file...
let yourModule = await require("path/to/your/module.js");
If you're loading a group of modules...
let _rGid = Symbol();
require("path/to/your/module1.js", _rGid);
require("path/to/your/module2.js", _rGid);
require("path/to/your/module3.js", _rGid);
require("path/to/your/module4.js", _rGid);
let [mod1, mod2, mod3, mod4] = await require(_rGid);

Explanation

Since this version of require is asynchronous, it's best to use await to unwrap the Promise values returned automatically for the single file case. This is made easier for you since all modules are wrapped in an asynchronous function. The group case loads all modules concurrently while processing them in the order they were requested, as soon as it is possible to do so. This means modules requested sooner do not have to wait for modules requested later to be loaded before being processed.

With this approach, modules only need to be written once and can be run anywhere. Hopefully, someone other than myself will find this useful.