why u no tests?

There doesn't seem to be an appropriate framework to do this kind of test and I have no interest in adjusting the test framework for this very minor change. All the existing tests pass. Feel free to add tests or reject this pull request based on this response.

He's right, I think we only have diff based testing in place atm. We should change that :D

You could pass Infinity though.

I think in that case intent would be more clear.

makes sense. The diff testing is pretty slick though.

@GEDDesign I wouldn't get rid of diff testing at all

Amended my commit, I forgot you guys don't like readable code so much :P

-Infinity won't work when using the plugin from the command line as it is not valid JSON. I'm ok with -1, just say the word. I think 0 is pretty clear though (as in: "zero file size limit").

I do like the url definition improvements though in this patch

But to be honest if we are gonna special case 0 might as well consider false to disable the limit.

Oh nevermind we got that. We should document it then, and I'm down to merge it

limit: 0 could be interpreted as "limit it to zero". What about limit: false?

Yep, in that regard limitting to zero is same as limiting to -1 (or -Infinity but that's overkill for file sizes). But the intent of limiting to zero in this case is to disable it, which is what confused me haha

Pick one now.

So I guess the optimal solution would be:

if ('number' == typeof options.limit && buf.length > options.limit)

0 doesn't get special treatment, you can still disable limits with false or Infinity

Although you could also disable limits with true haha, but yeah, that's why we need docs.

done.

Now it's not defaulting to 30000. I meant sizeLimit in my comment above, sorry about that.

Fixed in master