Was the input validation removed? Might be nice to mention that. I fully agree with removing it BTW, but I am confused now.

Needs more random tests. Some tests with randomly chosen input functions as well, at least ( you can just do some random calculations that always succeed in those functions ).

pipeline is passed binary functions, but returns a unary one. Make that explicit?

Also, the last input function should have the identity function as its next. Also make that explicit? That also explains why pipeline() should return id. People who don't know Monoids, not knowing any better, might pass null instead of id.

  typeof(createPipeline());//Function
  createPipeline()(true);// true
  createPipeline()(false);// false

This really should be part the spec: pipeline() should return the identity function. It should therefore be in the description proper, not hidden away in the examples.

Adding some more structure to the description may help us, and yourself as well, fully comprehend it. You might have sections Task, Examples and Inspiration, with Task containing all of the specs and none of the examples. Keep different things separated.

I would suggest to have pipeline accept either (...fns) or an Array of Functions, not both. Why complicate things?

Callers can easily add or remove a pair of square brackets, you're not really making things easier on them, and it's not essential to the function composition.

I'd suggest passing an Array; it's the cleanest way to pass in a single, consistently typed object that may contain zero or more consistently typed objects ( i.e. functions ). ( It also makes some translations easier. )

Not the greatest description.

Apparently, we are to implement function composition,

then there's an external link ( that won't be read ), some code I can't read because I only know JavaScript, and that is not JavaScript ( I don't even know if it's some variant of C or Java ), and the function of which is entirely unclear,

then there's "do function composition" again, but without any actual specification, and with some "order" that is also unspedcified ( "the" ), ( I may not speak C, but I do speak Haskell, where function composition is right to left by default! )

then there's a couple of examples that won't be read BECAUSE THEY ARE EXAMPLES - examples should not specify additional requirements, they should illustrate what has already been specified,

and finally there's something about making a request. I have no clue what that is about.

The example tests introduce a requirement to silently ignore invalid input, which is wrong in several ways.

Descriptions should be self-contained, so external references should not be essential ( they may actually not be in this case, I don't know ). They should be complete without resorting to specifying by example. And preferably, they should be concise, without inessential cruft in essential sections. Also, consider your target audience - JavaScript preogrammers. If you have to show code, make it JS code. Give examples their own section. And specify what we are to do ( and not do ) in the Description itself, not in examples, not in tests, and especially not in external links.