New Release

[svozza]

There's been a lot of new features that have been added since the last release, it might be best to pull the trigger on this sooner rather than later. Here's a list of all the changes, I think we should copy and paste it into the release notes in the Releases section.

New additions

• drop: Ignores the first n values of a stream and then emits the rest. support drop(), issue #11 #75 Tidy up support for drop() PR #244
• done: Calls the supplied function once the stream has ended. Implements done, modifies each to return a stream #161
• sort: Collects all values together then emits each value individually but in sorted order. Added Sort as of Issue #50 #169 Adds sort stream transformation incl. tests #245
• streamifyAll: Takes an object or a constructor function and returns that object or constructor with streamified versions of its function properties. _.streamifyAll #226
• Iterator Support: ECMA2015 (aka ES6) style iterators can now be passed to the Highland constructor function. add iterator functionality and tests #235
• slice: Creates a new stream with the values from the source in the range of specified in thestart and end parameters. Add slice function #250
• batchWithTimeOrCount: Takes one Stream and batches incoming data within a maximum time frame into arrays of a maximum length. Add _.batchWithTimeOrCount #284

Improvements

• each now returns an empty stream rather than nothing. Implements done, modifies each to return a stream #161.
• Ensure through propagates Node stream errors. Ensure _.through Propogates Node Stream Errors #240
• Preserve this context of wrapped function when using wrapCallback. Keep context in wrapCallback (and use wrapCallback in streamifyAll) #248
• Update tranduce to use latest version of transformer protocol. Update to latest transformer protocol & use init (Resolves #260). #261

[vqvu]

+1 on new release.

One more improvement

• each now returns an empty stream rather than nothing. Implements done, modifies each to return a stream #161.

[svozza]

Ah I'd missed that one. Incidentally, if we're finally bringing in drop should we also merge slice (#250)?

[jeromew]

I tried to make a release but eslint is not happy when calling npm test

lib/index.js
2896:40 error err is already declared in the upper scope no-shadow
3281:29 error memo is already declared in the upper scope no-shadow
3291:27 error memo is already declared in the upper scope no-shadow
3987:18 error Empty block statement no-empty

✖ 4 problems (4 errors, 0 warnings)

do you have the same issue on your side ? it is probably due to recent commits.

[vqvu]

Slice has optional arguments. Not sure what to do about that...

@jeromew, that's strange. I don't see it. Fresh clone and everything.

On Thu, Apr 9, 2015 at 3:22 PM, jeromew notifications@github.com wrote:

I tried to make a release but eslint is not happy when calling npm test

lib/index.js
2896:40 error err is already declared in the upper scope no-shadow
3281:29 error memo is already declared in the upper scope no-shadow
3291:27 error memo is already declared in the upper scope no-shadow
3987:18 error Empty block statement no-empty

✖ 4 problems (4 errors, 0 warnings)

do you have the same issue on your side ? it is probably due to recent
commits.

—
Reply to this email directly or view it on GitHub
#267 (comment).

[apaleslimghost]

It's possible to configure Travis to release to npm when a tagged commit passes. Do we want to consider this so we don't have to wait for @caolan or @jeromew to release?

[vqvu]

Wouldn't this expose their NPM credentials to the public? Unless travis encrypt uses a repository-specific public key.

On Fri, Apr 10, 2015 at 1:52 PM, Matt Brennan notifications@github.com
wrote:

It's possible to configure Travis to release to npm when a tagged commit
passes http://docs.travis-ci.com/user/deployment/npm/. Do we want to
consider this so we don't have to wait for @caolan
https://github.com/caolan or @jeromew https://github.com/jeromew to
release?

—
Reply to this email directly or view it on GitHub
#267 (comment).

[svozza]

Regarding slice, I had noticed that although it's worth noting that it actually doesn't affect the currying. These all work as expected:

var arr = [1, 2, 3, 4, 5];

var first = _.slice(1);
var second = _.slice(1, 4);

first(3, _(arr)).toArray(_.log);
//=> [2, 3]

second(_(arr)).toArray(_.log);
//=> [2, 3, 4]

I prefer fixed arity functions though so a solution would be to just remove the default values in slice and be explicit in the implementation of drop:

Stream.prototype.drop = function (n) {
    if (n <= 0) {
        return this;
    }
    return this.slice(n, Infinity);
};
exposeMethod('drop');

[vqvu]

The problem with optional arguments has always been if people try to do

var drop5 = _.slice(5);
drop5(_([1, 2, 3, 4, 5])).toArray(_.log);
// => an error.

Not having optional args means people can't accidentally mess up like this. But, I'm also OK with relaxing our stance on optional args if we put a warning in big red letters in the docs that says the top-level slice requires an explicit end parameter. We'll just be pushing the hard work to the user.

[svozza]

I think I would rather keep things consistent and just have the blanket rule that transforms don't take optional arguments, they complicate the API and once that genie is out of the bottle it's hard put it back in.

[vqvu]

I don't feel strongly either way, but slice is so ubiquitous that not having end be optional could cause the same kinds of confusion. Or we could implement drop and take in terms of a slice-like function, but not expose a slice transform.

[svozza]

Sorry, meant to reply to this. slice is quite useful though so it would be a shame to lose it. Does anyone else have any input? I'll go along with the consensus.

[vqvu]

We could go the reduce route and have a slice1.

On the other hand, slice(start, end) is equivalent to .drop(start).take(end - start).

[caolan]

I'd vote for keeping fixed arity, I understand this would likely trip people up in the case of slice though. Any more suggestions on alternative names for slice? Perhaps 'substream(start, end)', similar to substr()?

[jeromew]

@vqvu ok ; after removing node_modules altogether + a fresh npm install, the linting issue has disappeared.

I still don't understand it because it looks like the

2896:40 error err is already declared in the upper scope no-shadow

issue really exists in the code line 2896 (there is an err variable used by the closure that shadows the err from the upper scope)

am i misunderstanding this 'no-shadow' directive ?

[jeromew]

@svozza you said

I think we should copy and paste it into the release notes in the Releases section.

I think we should use the CHANGELOG file instead. It hasn't been used since 2.0.0 but should probably be used from now on.

regarding other options for slice, there could be cut, extract, section. cut is the word used for video cutting for instance when you want to extract a slice of a video.

[svozza]

Yeah, I just mentioned the Releases section because I saw it on the Bluebird page but changelog is as good a place as any. If we change the file name to changelog.md we can get the markup to work in it as well.

[vqvu]

We'll want to fix #205 before we release or the page that gets generated will be broken again.

@jeromew Perhaps the no-shadow was turned off by default in a later version of eslint? We don't explicitly enable that check in our .eslintrc.

I like substream since cut could also mean split (at a first glance).

[vqvu]

Thought about it some more, and I now think it's just fine to have slice without the optional argument (so objection withdrawn! :)).

After all, if I was OK with slice and slice1, then I should be OK with slice and drop.

The PR is fine to merge, I think, after applying @svozza's proposed fix.

[jeromew]

@vqvu so if I understand well you had the main objection regarding the slice name but that objection is gone now. @caolan was your message an objection also or do you agree with the slice name ?

[vqvu]

@jeromew Yes.

[svozza]

I'd say everything for this release is merged now, we should depoly to NPM as soon as possible.

[jeromew]

Sorry everyone about the delay.
I updated the CHANGELOG, renamed it CHANGELOG.md, mentioned batchWithTimeOrCount that was merged in between and pushed 2.5.0 to npm.
thanks to everyone for this release !