Allow multiple versions of tchannel to be require()d.

[lxe]

Tchannel should't make any assumption about the module tree in which it is in. Let's assume we have the following node_modules tree:

$ npm ls tchannel
top-level-project@1.0.0 /Users/aleksey/devel/top-level-project
├─┬ dep1@1.0.0
│ └── tchannel@3.5.0
├─┬ dep2@1.0.0
│ └── tchannel@3.6.0

Both dep1 and dep2 have tchannel as dependency matching all minor version up to 4:

"dependencies": {
  "tchannel": "^3.5.0"
}

Running npm install on this tree will (rightfully) mark both 3.5.0 and 3.6.0 versions as valid and matching their respective semver ranges.

I think it's a very bad practice for a module to expect a shape of the project's entire modules tree in which it is.

[Raynos]

TChannel is a singleton. There should only be one.

We enforce this.

[lxe]

TChannel is a singleton. There should only be one.

We enforce this.

There are better ways:

• https://github.com/isaacs/node-graceful-fs#global-patching recommends not to do this in a library, but doesn't throw if it runs twice
• https://github.com/bnoordhuis/node-heapdump/blob/master/lib/main.js is designed to be a singleton, yet there isn't anything in it that throws if it's not
• https://github.com/tlrobinson/long-stack-traces is a signleton, yet it does not throw
• You know that https://github.com/Raynos/format-stack is a singleton and it does not throw.
• etc..., etc...

You should warn, document, but never just throw an error. This causes unpredictable behavior across builds.

[Raynos]

I agree there are better ways in an open source project to do this. However we have a genuine support problem that must open source projects do not have.

We've had an issue in the past where engineers created two instances of tchannel and advertised twice in the same process. This created a weird edge case in terms of load balancing behavior and they reported it as a bug.

When we said "I'm sorry; you cant create two tchannels. that's not a supported feature" they were really upset. They mentioned that we must support the library even if its used incorrectly. They mentioned that if we want to stop people from using it incorrectly we should throw.

I agree with this trade-off. We throw when TChannel is used in an unsupported fashion and we have to support all other use cases and permutations in which the library is used.

However to accommodate your need; I will add a global.TCHANNEL_UNSUPPORTED_MODE = 'I know what I am doing'; that allows you to opt out of support and use TChannel in unique unsupported ways.

This causes unpredictable behavior across builds.

As an aside shrinkwrap is the recommended way to get predictable behavior across builds ;)