lloydcotten / common-mq Goto Github PK

Calling the AWS.SQS.createQueue will work and return the QueueUrl if it exists AND matches all the attributes. But if the queue attributes change, or options change, it returns an error and won't start. This is not necessary, as we can still use a queue with different attributes if use AWS.SQS.getQueueUrl method instead. We should try the getQueueUrl first and if that fails, call the createQueue method.

• Add CHANGELOG.md starting with v0.3.0 release

• Add integration tests
• Update README to add information about unit tests vs integration tests and dependencies required

• TravisCI
• AppVeyor
• Coveralls

Before breaking support for Node.js v0.10.x (in common-mq v1.0.0), we want to release another version with updated tests and cleaned up examples, API, docs, and latest supported dependencies.

• Update deps to latest version supported by Node.js v0.10.x
• Update package.json version attribute
• Publish to npm

• Implement eslint
• Correct lint errors / warnings

Need to cleanup the examples and add working examples for all three providers. Need to:

• Rename examples/common.js to reflect actual content (SQS example)
• Ensure zeromq example is working and fix as necessary
• Add an amqp example
• Add examples to .npmignore

node-amqp turns out to be no longer very well recommended by amqp / node.js community. amqp.node is a better option. We should swap out this dependency.

• Update CHANGELOG.md
• Update package.js version
• Publish to npm

• Upgrade to use latest es2015 features available (where it makes sense)
• Upgrade dependencies to latest supported versions

Providers should inherit from a base class. This should address the issue that some providers do not have an ack() method.

• Add yarn.lock

• Should list only supported providers
• Fix zeromq reference
• Need to add provider specific option documentation
• Review and update API as needed
• Fix code blocks to use backticks and language specs where possible

mq.connect(...). Is this caching the connection for subsequent messages? Looking in a use case where messages are going to different queues based on message content and similar message types should not connect again and use the existing connection (somehow).

It would be nice to support as many queue providers as possible. Please comment below if you would like to see common-mq support a particular currently unsupported provider.