Old dependencies

[jayvdb]

This package is using some quite old versions of dependencies, such as split2 0.2.1 when the latest is 2.1.1.
In the case of split 0.2.1, this is likely the cause of some junk in our docker image.
See coala/docker-coala-base#120

[jayvdb]

@mcollina can you confirm that the split2 dependency can be upgraded from 0.2.1 to 2.1.1 painlessly.

[mcollina]

From 0.2.1 to 2.0.1 is a huge step, but it should be painless.
Several things are different between those two versions, so you'd want to bump he major of ndjson as well.

[jayvdb]

@mcollina, are all the options for parse in 0.2.1 still supported?
That appears to be the only usage in this package:
https://github.com/maxogden/ndjson/blob/2659c24280d45aaf38b33bf7beed2ea34f424e48/index.js#L24

[mcollina]

Yes it's fine. v2 just handles correctly utf8 chars, plus it's an updated dependency on readable-stream.

[jayvdb]

So why wouldnt it be backwards compatible, or...
why would it need to be a major release of ndjson?

[mcollina]

because I consider a substantial change of the implementation a major change, ad it might introduce bugs.

It's up to @maxogden and @finnp.

[millette]

If it follows semantic versioning, quoting:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

It's all about compatibility, nothing about the implementation itself. If you don't change the interface (including supported node version), I suggest you only make it a PATCH change.

[mcollina]

As the maintainer of both split2 and readable-stream, I still recommend a major bump.
Specifically, split2 handles correctly utf8 chars, and that alone can cause applications using this to behave differently: they can break, ence the major bump. So yes, it’s about compatibility.

[millette]

Good point @mcollina :-)

Sorry if that came out pedantic,