prevent 'to: wrong argument' output caused by shelljs

[az7arul]

`to` method in shelljs expects two arguments and throws an error if there is no second argument, so passing an extra string to keep it happy

This fixes #127 although I am not entirely sure if we should do it or not.

@jprichardson thoughts ?

[jprichardson]

Thank you.

I'm definitely OK with accommodating shell.js and its bad behavior solely because it's so commonly used. I like this hack.... I'm wondering though, does it make more sense to just hardcode the native string properties? That adds more to the payload, but it feels more correct. IDK, maybe what you have is good enough. Thoughts?

[az7arul]

This hack does allow adding own String.prototype properties ( which seems to me a bad idea but it is done i.e shelljs) since the current implementation wraps them if they were added before requiring string.js.

Having said that, If adding hardcoded property does not break anything I think thats the way to go.

[steveoh]

is this going to get merged?

[jprichardson]

Yeah, I'll do it now... give me a few mins...

[jprichardson]

Published as 3.1.1.

[steveoh]

[steveoh]

@jprichardson I'm noticing a side affect with this. When this is executed with the shelljs's overload of to a file is written named string with the value test. This is a bit crazy, but do we need to put more logic in here to tame shell js for their actions?

[jprichardson]

Grrrr on shelljs. Would skipping the String.prototype.to method maybe work? @az7arul thoughts?

[az7arul]

@jprichardson we can have a list of string prototype methods that we allow in stringjs instead of going through all String.prototype methods ( some of which can be non native ) and calling them with string arguments to determine if they return string or not.

This approach should get rid of these kind of problems but might be a breaking change for people who are relying on stringjs to recognize string methods that they have added themselves and allow chaining.

[az7arul]

we need to skip both to and toEnd