path: iojs@1.6.0 breaks compatibility with previous versions

[feross]

In iojs 1.5.1:

> path.dirname(undefined)
'.'

> path.dirname([ 'sup/dude' ])
'sup'

In iojs 1.6.0:

> path.dirname(undefined)
TypeError: Path must be a string. Received undefined
 at assertPath (path.js:8:11)
 at Object.posix.dirname (path.js:539:3)
 at repl:1:6
 at REPLServer.defaultEval (repl.js:124:27)
 at bound (domain.js:254:14)
 at REPLServer.runBound [as eval] (domain.js:267:12)
 at REPLServer.<anonymous> (repl.js:277:12)
 at emitOne (events.js:77:13)
 at REPLServer.emit (events.js:166:7)
 at REPLServer.Interface._onLine (readline.js:195:10)

> path.dirname([ 'sup/dude' ])
TypeError: Path must be a string. Received [ 'sup/dude' ]
 at assertPath (path.js:8:11)
 at Object.posix.dirname (path.js:539:3)
 at repl:1:6
 at REPLServer.defaultEval (repl.js:124:27)
 at bound (domain.js:254:14)
 at REPLServer.runBound [as eval] (domain.js:267:12)
 at REPLServer.<anonymous> (repl.js:277:12)
 at emitOne (events.js:77:13)
 at REPLServer.emit (events.js:166:7)
 at REPLServer.Interface._onLine (readline.js:195:10)

This appears to be a bug introduced by this PR: #1153.

This suddenly started causing tests in webtorrent and browserify to start failing. Here's an example.

[rvagg]

/cc @cjihrig

[cjihrig]

Looking.

[rvagg]

This is all I can think of here, expose any API to a large enough audience and you're sure to have some of them using unexpected edge-cases as an integral part of their workflow.

I'm not convinced we should "fix" this but perhaps in-the-wild use is reason enough?

/ @iojs/tc please weigh in

[cjihrig]

The case for undefined returning '.' makes some amount of sense. The array usage does not. Neither of these uses are documented or tested. How do we want to proceed?

[rvagg]

I don't have a strong opinion on this and am tempted to call out those relying on edge-cases to fix bugs in their own code, but perhaps that's not very community-friendly of us and we should just be paving cowpaths!

[rvagg]

Alternative here is to print a deprecation warning on anything other than strings, that might be the gentle way to proceed. I honestly can't make sense of path.dirname([ 'sup/dude' ]).

[johnsoftek]

+1 for deprecation warning

[feross]

The array use case is weird – agreed. I have no idea how/why that was working before.

path.dirname(undefined) returning '.' makes more sense, though.

[feross]

Ah, I figured out why the array parameter was working:

> path.dirname([ 'sup/dude', 'sup2/dude2' ])
'sup/dude,sup2'

The array was being toStringed. This was definitely a bug in webtorrent.

I still think we should consider making path.dirname(undefined) work like before.

[cjihrig]

Some functions flat out break if a string isn't passed. I'm trying to identify those, and will remove the check from the others.

[rvagg]

I'll put this in the 1.6.1 bucket if we can get it done today, is that reasonable @cjihrig?

[cjihrig]

Coming in a few minutes.