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

wrapup-partition

v0.0.8

Published

Convert Node/CommonJS modules for the browser with on demand loading of JS files

Downloads

8

Readme

wrapup-partition

Transform CommonJS modules to combined AMD (requirejs) files. Pack multiple related modules together, and make your initial pageload smaller.

npm install wrapup-partition

example

wrapup-partition partition --map mapping.json --output build

Configuration file

In the mapping/configuration file you can define which modules end up in which output file. Here you can group files together.

{
    "main.js": [
        "homepage",
        "sidebar"
    ],
    "dialog.js": [
        "profileDialog",
		"tweetDialog"
    ]
}

Modules required by a file specified in this configuration are added to that file if this module isn't required by some other module.

For example consider this graph:

        homepage      tweetDialog
		      \        /     \
		       \      /    parseTweetText
               animation

Even though animation or parseTweetText are not specified in the configuration, parseTweetText is added to dialog.js, because it only has parents that are also in the dialog.js. animation however is added to the main.js because its parents are in multiple files.

require

You can use the node/commonjs require() function as many times you like, except when you want to split the parts. In that case you should use the asynchronous requirejs function. The main JavaScript file configures requirejs so you can use the original module names.

homepage.js

function openTweetDialog() {
	requirejs(['tweetDialog'], function(dialog){
		dialog.open();
	});
}

This automatically loads the dialog.js file once.

In all other cases, you can simply use the require function, for example to load the tweetParser

tweetDialog.js

var parse = require('./parseTweetText');
exports.open = function() { /* ... */ };

Rewriting module names

Sometimes module names can get very long, especially when your original file structure contains multiple levels. That's why wrapup-partition can rename module IDs. This works very good, except when you want to dynamically load other modules. Thats is where you need to know the renamed ID.

This can be solved by using the standard wrapup-require or wrapup-names modules. The first one contains a requirejs like function that automatically maps the module names, and the second contains a look-up object.

function openTweetDialog() {
	// require the wrapup-require module first
	requirejs(['wrapup-require'], fuction(req) {
		// then use it to require the tweetDialog
		req(['tweetDialog'], function(dialog) {
			dialog.open();
		})
	})
}

In reality the tweetDialog module looks something like

define('c', ['require', 'exports', 'module', 'd'], function(r, e, m){
	var parse = r('d');
	e.open = function() { /* ... */ };
});

instead of:

define('tweetDialog', ['require', 'exports', 'module', 'parseTweetText'], function(r, e, m){
	var parse = r('parseTweetText');
	e.open = function() { /* ... */ };
});

When you require the wrapup-names you will get an object like:

{
  "c": "tweetDialog",
  "d": "parseTweetText"
}