Just moving the Rxjs as peer dependency on order to provide better support for consumer and their node_modules.

Currently a message can be bound to a single handler, e.g.

export const MESSAGE_HANDLER_PAIRS: MessageHandlerPair[] = [
  { message: ProcessPaymentCommand, handler: ProcessPaymentCommandHandler }
];

We'd like to have the chance to connect multiple handlers to a single message. A possible interface would be:

export const MESSAGE_HANDLER_PAIRS: MessageHandlerPair[] = [
  { message: ProcessPaymentCommand, handlers: [ ProcessPaymentCommandHandler ] }
];

NOTES:

• The above interface would introduce a breaking change.
• The above example makes use of https://github.com/tafax/js-bus/blob/master/src/lib/resolver/class-map.handler-resolver.ts as resolver.

Going to submit a PR soon 😄

We want to improve the building process in order to provide these artifacts:

• UMD
• ESM5
• ESM2015
• FESM5
• FESM2015

Define these entries in package.json:

{
  "name": "js-bus", 
  "module": "./fesm5/js-bus.js", 
  "es2015": "./fesm2015/js-bus.js", 
  "esm5": "./esm5/js-bus.js",
  "esm2015": "./esm2015/js-bus.js",
  "fesm5": "./fesm5/js-bus.js",
  "fesm2015": "./fesm2015/js-bus.js",
  "main": "bundles/js-bus.umd.js", 
  "typings": "js-bus.d.ts",
  "sideEffects": false
}

TsConfig to module type:

• target es5 => umd
• target es5 => esm5/fesm5
• target es2018 => esm2015/fesm2015

References:

• https://docs.google.com/document/d/1CZC2rcpxffTDfRDs6p1cfbmKNLA6x5O-NtkJglDaBVs/edit#
• https://webpack.js.org/configuration/configuration-types/#exporting-multiple-configurations
• https://github.com/liady/webpack-node-externals
• https://github.com/webpack-contrib/terser-webpack-plugin
• https://marcobotto.com/blog/compiling-and-bundling-typescript-libraries-with-webpack/
• https://github.com/Hotell/typescript-lib-starter
• https://api-extractor.com/

We would like to improve the doc and make some examples of usage for the library. Just it! :)

The devDependency rollup was updated from 1.27.9 to 1.27.10.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

rollup is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Skipping the version 0.1.0 since we previously unpublished it on NPM. We can reuse it.

Due to the public publishing of the library, we want to update the release process to update the publishing of the library on NPM for each new version.

The devDependency rollup was updated from 1.14.2 to 1.14.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

rollup is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The devDependency @types/node was updated from 12.12.13 to 12.12.14.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The devDependency mocha was updated from 6.0.2 to 6.1.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

mocha is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

We moved from BitBucket to GitHub and published a first version of this library in NPM.

Update the README to reflect this changes.

We provide the ability the handler resolution through a service locator.

const resolver = new ServiceLocatorAwareCallableResolver(aFunction);

aFunction is a function object that is able to get an identifier (the same you use for the mapping) and provide a well-defined handler that is a handler that has a method called handle.

Even if you can create your own resolver using the provided interface CallableResolverInterface, the service locator resolver is very useful for integrating the library in many frameworks.

We'll provide a way to avoid passing a function so you can avoid handling the function scope. Instead, we'll introduce an adapter that you can use to decoupling you specific service locator to what the library expects to use.

const myFrameworkLocator = ...;

const jsBusLocatoAdapter = new JsBusLocatorAdapter(myFrameworkLocator);
const resolver = new ServiceLocatorAwareCallableResolver(jsBusLocatoAdapter);

JsBusLocatorAdapter will be a class conform to a specific interface that the consumer needs to create based on its own service locator.

We'll leave the ability to use the function as before, but will become deprecated.

The devDependency rollup was updated from 1.9.2 to 1.9.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

rollup is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Just remove the unused dependencies to avoid tracking them.

Once the handlers are resolved we use function binding to handle it.
It is originally implemented to make the library as agnostic as possible. It doesn't work very well with TypeScript and in general, the binding is a bad technique.

// Uses the bind to maintain the scope of the object.
return handler.handle.bind(handler);

So, what we can do is returning an object instead of a binding function. To do that we have to introduce an internal interface to identify a handler.

Given that doesn't change the need to have a handle method in the handler object, for sure.

The current implementation of the check duplicated messages in the collection seems to not work if the code is minified.

We want to introduce a basic support for Travis CI in order to run our tests.

After upgrading to TypeScript 2.4.2, I experience an issue related to the handle method of MessageBusAllowMiddleware here https://github.com/tafax/js-bus/blob/master/src/Bus/MessageBusInterface.ts#L11
As usual, I'd like to handle the result of it as an Observable and to be able to apply RxJS operators.
Looks like the type checking became stricter and we need to explicitly mark the return type of handle as Observable now.

Also, since this repo was moved to GItHub, please update the NPM repo URL in the following places
https://github.com/tafax/js-bus/blob/master/package.json#L19
https://github.com/tafax/js-bus/blob/master/package.json#L29

Adds the coverall badge to the README.

If you map the same message to two different handles, right now, just the first mapping is used to resolve the handler.

const mapping = [
   { message: 'my message', handler: 'my handler' },
   { message: 'my message', handler: 'my other handler' },
];

When you execute the message you will get the my handler execution.

// Will execute `my handler` and will ignore `my other handler`.
messageBus.execute('my message').subscribe();

Anyway, it is not deterministic since the resolver will iterate the mapping and it will use the first one. To avoid this type of situations will introduce a specific error that is thrown when you try to map the same message to another handler.

// Will throw an error.
const mapping = [
   { message: 'my message', handler: 'my handler' },
   { message: 'my message', handler: 'my other handler' },
];

Make duplications check compatible with the minification.

Add support for snyk.io in order to maintain in sync the dependencies.

Right now, if you pass a message to the message bus you have to subscribe to the returned observable.

// Not executed.
messageBus.execute('message');

// Executed.
messageBus.execute('message').subscribe();

in order to execute the handler mapped to that message.

We want to allow consumers to subscribe only if they need to handle the subscription callbacks.

// Executed.
messageBus.execute('message');

// Executed.
messageBus.execute('message').subscribe();

Your message will be executed twice if you call execute twice.

// Executed.
const execution$ = messageBus.execute('message');

// Just subscribe to execution observable.
execution$.subscribe();