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

broccoli-global-exporter

v0.6.4

Published

Exports global variables using ES6 module syntax.

Downloads

41

Readme

Build Status codecov.io

broccoli-global-exporter

Exports global variables using ES6 module syntax.

This is useful for working in a code base that is stuck with code that doesn't use modules, such as legacy or vendor code that we do not own, so I wrote this plugin to shim them and import them using modules. This doesn't provide any mechanism for specifying imports or requires, though I welcome additions.

Shimming dependency management is, in my experience, a very error prone approach, with a near guarantee of breaking. The goal of this module isn't to make non-modules walk like modules, but to allow them to be included via module loaders to free client code written as modules from the burden of having to import something from the global namespace, and enable you to inject a better dependency later on without changing the consumers.

Example usage

In your Brocfile.js:

var exportGlobals = require('broccoli-global-exporter');

module.exports = exportGlobals('src', 'foo.js', {
  defaultExport: 'Foo',
  exports: ['bar', 'baz']
});

this will augment the input file (foo.js) with the following export statements:

export default Foo;
export bar;
export baz;

You can also modify more than one file in the same tree by passing an object mapping the file name relative to the root of the tree to an object containing either the defaultExport or exports properties (or both):

module.exports = exportGlobals('src', {
  'foo.js': {
    defaultExport: 'Foo'
  },
  'bar/baz.js': {
    exports: ['bar', 'baz']
  }
});

Module formats

The default format is ES2015 modules, but CommonJS is also supported. This can be handy if you're going to compile your ES6 modules down to CJS anyway, you can avoid the overhead of invoking your compiler for something we can do up front anyway.

Supported moduleTypes:

  • ES6 modules - es2015 (default)
  • CommonJS - cjs
module.exports = exportGlobals('src', {
  'foo.js': {
    defaultExport: 'Foo',
    exports: ['bar', 'baz']
  }
}, {
  moduleType: 'cjs'
});

This will yield the following output:

exports.bar = bar;
exports.baz = baz;
Object.defineProperty(exports, '__esModule', {
  value: true
});
exports['default'] = Foo;

This CJS output is compatible with the way code compiled with babel looks for ES6 default exports by checking the __esModule property on the object returned from require. If you have no default export, this code will not be emitted.

Contributing

Issues and PRs are very welcome. PRs are likely to be merged if you don't change the existing tests too much, code coverage doesn't drop, and you respect the existing code style, which is pretty heavily enforced by the linter (so don't suppress it).