Current firstname.lastname@example.org is compatible with connect master. v0.3.2 is not. Find out why and fix it.
Can you elaborate on "incompatible with connect master" ? There are a lot of ways union could be incompatible.
All the following connect middlewares do not work with union v0.3.2 (they work with union v0.3.0)
Does union have tests for these? That would certainly help ensure a lack of breakage in the future.
http://github.com/pksunkara/connect-union, which is a fork of connect, replaces the connect server in their test suite with union, thus testing union compatibility with each and every connect middleware
So why isn't this part of our test suite?
Because maintaining it becomes a very difficult task, as it constantly needs to be updated from connect and union shim needs to be applied. me and @dscape discussed over it and decided to leave it in a seperate repository.
Okay, that makes sense, but what about running those tests as part of the test suite?
@pksunkara Can you provide empirical evidence for your claims? I'm seeing test/body-parser-test.js pass:
$ vows test/body-parser-test.js --spec
When using union with connect bodyParser() a request to /
✓ should respond with a body-decoded object
✓ OK » 1 honored (0.016s)
Tested with email@example.com
After extensive testing by me, I finally found what the problem was. In my http://github.com/pksunkara/connect-union tests, I didn't provide buffer: false to the server. I assume some logic for that has changed between v0.3.0 and v0.3.2.
It should be documented that for union to be compatible with connect, we need to set buffer to false
But, if we are going to use connect with flatiron and firstname.lastname@example.org, we will get errors because buffer is not set to false in http://github.com/flatiron/flatiron/blob/master/lib/flatiron/plugins/http.js#L74