indexzero / broadway

Lightweight App extensibility and hookable middleware customization.

indexzero

Fancy animated gif: [PENDING]

$ npm install indexzero

and

console.log(require('indexzero'));

To get my contact information.

Credits

Thanks to John K Paul for the idea, and Guillermo Rauch for pointing it out!

broadway's Issues

Order of .init() for plugins not guarenteed

Needs to be fixed.

Do not use `broadway.plugins.log` by default

I don't want to use winston and broadway.plugins.log ends up overriding app.log.

[Browser build] Asynchronous Module Definition

Hi @mmalecki @pksunkara

Can we make builds that comply with the Asynchronous Module Definition?

Something like:

  if (typeof define === 'function' && define.amd) {
    define(function() { return App; });
  } else {
    exports.App = App;
  }

Should be an easy fix.. right?

Add uninit

I would need an unit similar to init so that I can cleanup my nodejs modules and lose all open devices such as serial ports, tcp connections etc...

Pass app as a parameter to plugins

Currently to access the application within a plugin you have to use this in .attach.

This becomes painful when you use a function like _.bindAll on your plugin. Since you no longer have access to the app in your attach function.

It's also painful because I can't call other methods of the plugin in the attach function using this.

I suggest changing the signatures to

• attach(options, app);
• init(done, app);
• detach(app);

This will give plugin writes a little more freedom in how they arrange their plugin and how they interact with the application.

Remove all plugins from `broadway`

Moving forward it seems that we should move all of the plugins in broadway into an intermediary library which flatiron and others can depend on. Those who simply want the core extensibility functionality can use broadway unencumbered.

@mmalecki @pksunkara Thoughts?

App.prototype.inspect

App.prototype.inspect is currently being set (at the bottom of app.js) to an empty function.. while this doesn't really impact it's general usage, node checks object.inspect for custom inspection info and it does have an annoying side effect of causing objects that are instances of broadway.App to return undefined to the node REPL ..

To see what I'm talking about run node ... and do var broadway = require('broadway') then var app = new broadway.App() ... now if you type app and hit enter it will say undefined.. it of course is not undefined.. typeof app returns object ...

Cannot find module 'graceful-fs'

This occurs when I tried to require "broadway" on client side.

I think this is fixed on "rimaf" v2 version which is included on "utile" latest version.

Please, update "broadway" to use "utile" latest version.

Thank you,
Marko Jankovic

Broken compatibility

Broken compatibility with the example found on "http://flatironjs.org/". Could someone provide a transition guide or something similar?

Add ability to define plugin `npm` dependencies

I've been running into a common idiosyncrasy with plugins that require dependencies. Looks like a chance to improve the API / set a best practice.

Take for instance, a jade plugin:

/**
 * Jade broadway plugin.
 */

var jade;

exports.attach = function (options) {
  this.jade = {
    render: function (view, data, cb) {
      var html;
      try {
        html = jade.compile(view.template, options)(data);
      } catch (err) {
        if (cb) { return cb(err); }
        throw err;
      }
      if (cb) { return cb(null, html); }
      return html;
    }
  }
};

// `exports.init` gets called by broadway on `app.init`.
exports.init = function (done) {
  try {
    jade = require('jade');
    done();
  } catch (err) {
    done(err);
  }
};

Notice App.init contains a try / catch block around the require statement to determine if jade is available.

It seems this is going to be a common problem ( plugins that require dependencies ).

A good potential solution would be being able to specify npm dependencies on a per plugin basis.

// `exports.dependences` contains hash of npm deps for plugin
exports.dependences = {
  jade: "*"
}

Then, broadway and flatiron would intelligently be able to detect / load modules based on this new information.

Support App::remove

Currently plugins have attach and detach methods. App::use calls the attach method of a plugin. However there is no inverse of App::use.

I'd be nice if there was an App::remove that called detach on a plugin. A method that would be similar to nCore.remove.

I'll add a pull request in a few moments.

Setting default env causing problems

https://github.com/flatiron/broadway/blob/master/lib/broadway/bootstrapper.js#L31

This line has been causing us problems. If there is a config file loaded in nconf as a file store, the above line sets env in the literal store. Every time config.get('env') is called, it returns the literal store's value, not the file store's value. This is a major problem when the default app.env is development and your config file says "env": "production".

bootstrapper drops config options

exports.bootstrap = function (app) {
  app.options['config']        = app.options['config'] || {};
  app.options['config'].init   = false;
  app.use(broadway.plugins.config);
};

config options you may have passed to new broadway.App are dropped because App.prototype.use overwrites options[<plugin name>] with an empty object when no options argument is included ...

logging plugin: No way to set console loglevel

As far as I can tell, there isn't an obvious way to set the console loglevel with the logging plugin.

I have a pull request coming up that intends to fix this.

Init order and dependencies?

If I have a module called Database and other called Creatures where the Creatures module depends on a fully initialized Database in it's init method, how would I handle that?

Why is optimist in dependency list?

nt

Cannot add namespaced loggers

Adding namespaced Winston loggers via configuration seems to be broken. When I set the configuration like this:

app.config.set("log:namespaces:foo", { console: { colorize: true } });

then I would expect Broadway to configure a logger named foo for me with the stated configuration:

app.log.get("foo").info("Colored output here");

but this is not the case. I believe Broadway's log plugin is not picking up the configuration for namespaced loggers correctly. Probably the cause is here: https://github.com/flatiron/broadway/blob/master/lib/broadway/plugins/log.js#L103

Happy to submit a pull request if this is indeed a bug!

Hot Updates?

Would it be possible to support hot updates of plugins?

Octal number encoded incorrectly on 0.x

FlatIron still uses [email protected]: https://github.com/flatiron/flatiron/blob/master/package.json

But this branch contains numbers like 0755. It should be 0o755.

Make logging level last parameter in the event

That'd make these events much less logging-specific. For example, currently when I'm interested in some event (when writing a plugin for existing application), I have to write:

haibu.on('drone:start', function (_, app) {
});

because first parameter is the log level (not the thing I'm actually interested in - app parameter).

@indexzero You wrote that part. Opinions?

app.mixin(new hapi.Server());

Øpen discussion around what would need to change in the API to make this work.

Object.keys(new hapi.Server());

Reveals that there are a couple of places we will conflict as is today. The list is surprisingly small.

['start', 'root', 'log']; 

package.json from repo doesn't match npm

The package.json has been updated on the repo but it hasn't replaced the one on npm. Both repo and npm have v0.2.1 of this module but the file is still different. Differences are mainly version changes to a few dependencies.

Meta is polluted with event property

If something is logged by using the event interface of the logging plugin then the meta object is being polluted with an event property. See https://github.com/flatiron/broadway/blob/master/lib/broadway/plugins/log.js#L192

This means that if I log an object with an event property in it, it will be overwritten by the logging plugin. This is not desired as it changes others data.... (took me 2 hours to find this... :-( )

Should I make a pull request (only one line to remove because the added event property isn't used anywhere in the logging plugin nor Winston...) ?

dependency of eventemitter2-0.4.12 broken

Now version of eventemitter2 - 0.4.13

[Browser Build] Dependency or not?

For browser scripts file size is important... I don't know if it is a good idea to include EE2 with the build because people might already have it as a separate module included in their code base...

Overriding `.options()` method from express

Setting the options object is making it hard to create a route handler for an OPTIONS method request in express.

Update eventemitter2 Dependency to 0.4.2?

While installing forever, npm was complaining that:

npm WARN [email protected] package.json: 'contributers' should probably be 'contributors'

Which has been fixed in 0.4.2.

use it with browserify

This is more like a feature.

I'd like to use this broadway library with browserify, this means, in the client-side.

To aciheve that, I'd need to get rid of some plugins/libraries, like nconf, which uses fs.

Would you like to help to project ? maybe I could fork this into new one...

Anyway I'm pointing to you because you are the main architechts, I think this tool is very nice and it would be valuable to have it available in client-side.

Regards.

Publish current code with eventemitter2 0.4.3

In [email protected], [email protected] is used and it has some annoying bug with "**" events, so I just cannot used them.

I'm making a sandbox with a plugin system using brodway and intercom, and I'm relaying some events from intercom (wich uses eventemitter2 as well) to the broadway app using "anamespace::**". With [email protected] I just can't. I've seen You have updated the dependency to [email protected], which seems to work fine.

Could you just publish the current code as 0.1.8 (or 0.1.8-pre)?

Event-driven logging with Winston

I am trying to use Winston's namespaced logging by emitting events on the broadway app object:

broadway = require 'broadway'

app = new broadway.App()

app.init (err) ->
  app.log.add 'server',
    console: {
      level: 'error'
      timestamp: true
      colorize: true
    }
  app.emit ['log', 'error'], "log regular error"
  app.emit ['log', 'error', 'server'], "log error in server namespace"

I would expect the second error event to be logged by my configured server logger, but this is not the case. Digging into the source code of the log plugin, I found the line

if (ev === 'log') {
    namespace = parts[2] || 'default';
    logger = this.log.get('default');
  }

I changed it as follows to get the right logger for the namespace indicated by the event:

if (ev === 'log') {
    namespace = parts[2] || 'default';
    logger = this.log.get(namespace);
  }

Is this the right approach or am I missing something here? I'd be happy to submit a pull request!

Add more complex examples and extensive documentation

Examples should include some configuration, MVC and plugin usage

Better documentation is important because a new version is quite different with previous

Thank you!

app.init breaks when using multiple plugins and an init step

So I was trying to write some stuff in broadway and I ran across this problem:

var broadway = require('broadway'),
    app = new broadway.App;

// First, use a middleware that has a significant init stage.
app.use({
  attach: function (opts) {
    this.place = 'rackspace';
  },

  init: function (cb) {
    var self = this;

    // You actually get the same error if you drop the nextTick,
    // but I wanted this to be truly async.
    process.nextTick(function () {
      self.letsGo = function () {
        console.log('Let\'s go to '+self.place+'!');
      }

      cb();
    });
  }
});

// Second, try to add another plugin. It doesn't even have to *do* anything.
app.use({
  attach: function () {}
});

// When initializing, app.letsGo should get defined (by my understanding)
app.init(function (err) {
  if (err) {
    throw err;
  }

  // app.letsGo is undefined
  app.letsGo();

});

The corresponding stack trace from broadway looks like:

{
  "process": {
    "pid": 6807,
    "uid": 1000,
    "gid": 1000,
    "cwd": "/tmp/test",
    "execPath": "/usr/local/bin/node",
    "version": "v0.6.6",
    "argv": [
      "node",
      "/tmp/test/test.js"
    ],
    "memoryUsage": {
      "rss": 14753792,
      "heapTotal": 8667776,
      "heapUsed": 4865800
    }
  },
  "os": {
    "loadavg": [
      0.1015625,
      0.15185546875,
      0.1416015625
    ],
    "uptime": 18717.25650203
  },
  "trace": [
    {
      "column": 7,
      "file": "/tmp/test/test.js",
      "function": null,
      "line": 30,
      "method": null,
      "native": false
    },
    {
      "column": 5,
      "file": "/tmp/test/node_modules/broadway/lib/broadway/app.js",
      "function": "onComplete",
      "line": 86,
      "method": null,
      "native": false
    },
    {
      "column": 10,
      "file": "/tmp/test/node_modules/broadway/lib/broadway/features/index.js",
      "function": "Object.ensure",
      "line": 10,
      "method": "ensure",
      "native": false
    },
    {
      "column": 18,
      "file": "/tmp/test/node_modules/broadway/lib/broadway/app.js",
      "function": "ensureFeatures",
      "line": 92,
      "method": null,
      "native": false
    },
    {
      "column": 25,
      "file": "/tmp/test/node_modules/broadway/node_modules/utile/node_modules/async/lib/async.js",
      "function": null,
      "line": 105,
      "method": null,
      "native": false
    },
    {
      "column": 5,
      "file": "/tmp/test/node_modules/broadway/lib/broadway/app.js",
      "function": "initPlugin",
      "line": 108,
      "method": null,
      "native": false
    },
    {
      "column": 13,
      "file": "/tmp/test/node_modules/broadway/node_modules/utile/node_modules/async/lib/async.js",
      "function": null,
      "line": 97,
      "method": null,
      "native": false
    },
    {
      "column": null,
      "file": null,
      "function": "Array.forEach",
      "line": null,
      "method": "forEach",
      "native": true
    },
    {
      "column": 24,
      "file": "/tmp/test/node_modules/broadway/node_modules/utile/node_modules/async/lib/async.js",
      "function": null,
      "line": 26,
      "method": null,
      "native": false
    },
    {
      "column": 9,
      "file": "/tmp/test/node_modules/broadway/node_modules/utile/node_modules/async/lib/async.js",
      "function": "Object.forEach",
      "line": 96,
      "method": "forEach",
      "native": false
    }
  ],
  "stack": [
    "TypeError: Object [object Object] has no method 'letsGo'",
    "    at /tmp/test/test.js:30:7",
    "    at onComplete (/tmp/test/node_modules/broadway/lib/broadway/app.js:86:5)",
    "    at Object.ensure (/tmp/test/node_modules/broadway/lib/broadway/features/index.js:10:10)",
    "    at ensureFeatures (/tmp/test/node_modules/broadway/lib/broadway/app.js:92:18)",
    "    at /tmp/test/node_modules/broadway/node_modules/utile/node_modules/async/lib/async.js:105:25",
    "    at initPlugin (/tmp/test/node_modules/broadway/lib/broadway/app.js:108:5)",
    "    at /tmp/test/node_modules/broadway/node_modules/utile/node_modules/async/lib/async.js:97:13",
    "    at Array.forEach (native)",
    "    at /tmp/test/node_modules/broadway/node_modules/utile/node_modules/async/lib/async.js:26:24",
    "    at Object.forEach (/tmp/test/node_modules/broadway/node_modules/utile/node_modules/async/lib/async.js:96:9)"
  ],
  "level": "error",
  "message": "uncaughtException"
}

I'm going to dig into the code now that I have this stack trace (the one I saw when I discovered this with vows was less detailed) but I have a feeling I'm out of my element here.

App.use not calling back under error

Was accidentally use'ing a module with a name but no init or attach, and app.use(module,opts,function(err){.....}) was not calling the callback. Expect the callback to still happen, err to be populated.

incomplete implementation of features.ensure()?

in /lib/broadway/features/index.js

exports.ensure = function (app, callback) {
  return callback();
}

It seems doing nothing except firing the callback. Should there be some test on methods supported by the app?