path: iojs@1.6.0 breaks compatibility with previous versions #1215

feross · 2015-03-20T00:11:19Z

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.

The text was updated successfully, but these errors were encountered:

rvagg · 2015-03-20T00:13:55Z

/cc @cjihrig

cjihrig · 2015-03-20T00:17:23Z

Looking.

rvagg · 2015-03-20T00:17:27Z

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 · 2015-03-20T00:22:54Z

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 · 2015-03-20T00:25:10Z

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 · 2015-03-20T00:26:43Z

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 · 2015-03-20T00:29:47Z

+1 for deprecation warning

feross · 2015-03-20T00:31:59Z

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 · 2015-03-20T00:34:59Z

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 · 2015-03-20T00:36:49Z

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 · 2015-03-20T00:42:04Z

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

cjihrig · 2015-03-20T00:42:49Z

Coming in a few minutes.

silverwind · 2015-03-20T00:47:08Z

I'm more in the camp of not supporting weird usage like path.dirname(undefined). This is definitely a user error which we mask by returning something.

This strongly reminds me of JS type coercion. Sometimes it's better to crash and burn, than to silently try to do the right thing™.

monsanto · 2015-03-20T00:53:24Z

I agree with @silverwind. Special behavior on undefined should be kept to a minimum. Getting an error on path.dirname(obj.mispelledProperty) is more important than "well it sorta makes sense."

cjihrig · 2015-03-20T00:54:55Z

FWIW, I agree completely. Making the APIs more restrictive cuts back on JavaScript wats. But, it is what it is.

RnbWd · 2015-03-20T00:55:04Z

I also agree with @silverwind - but the behavior should remain consistent for now. Maybe add it as a discussion in the next meeting?

feross · 2015-03-20T01:00:50Z

cc @substack

domenic · 2015-03-20T01:04:23Z

FWIW all string-accepting web APIs and built-in ES APIs to ToString on their arguments, instead of type-testing. I am surprised io.js is trying to break with that; it violates my expectations.

feross · 2015-03-20T01:06:03Z

Breaking working npm packages is not cool, even if it's the right API decision for iojs.

If we're going to make an API more restrictive in the inputs it accepts, we should strive to have a deprecation notice for a while first. As Rod says, it's the gentler way to proceed and nicer to users :)

a465840 added strict type checking for the methods in the path module. However, dirname(), basename(), and extname() actually had some undocumented uses in the wild. This commit loosens the type checking on those methods. Fixes: #1215 PR-URL: #1216 Reviewed-By: Rod Vagg <rod@vagg.org>

cjihrig · 2015-03-20T01:12:00Z

Fixed in 8de78e4

cjihrig · 2015-03-20T01:12:12Z

Let me know if you're still having problems.

feross · 2015-03-20T01:25:18Z

Thanks!

nodejs/node#1215

xaka · 2015-03-20T01:30:16Z

What you're saying is right, it's just it doesn't apply to this situation
IMHO. Have you ever seen language APIs coercing NULLs and VOIDs to
different types with different values? I personally haven't and would
consider it as an awful side effect. Such things cost a lot of money due to
longer debugging time. I think having a warning is the best (and must have)
option here, and it should go away in next releases.

On Thu, Mar 19, 2015 at 6:04 PM, Domenic Denicola notifications@github.com
wrote:

FWIW all string-accepting web APIs and built-in ES APIs to ToString on
their arguments, instead of type-testing. I am surprised io.js is trying to
break with that; it violates my expectations.

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

domenic · 2015-03-20T01:35:39Z

I have seen such a language, it's called JavaScript. It's very nice and much code depends on it.

silverwind · 2015-03-20T02:14:21Z

We still ❤️ Brendan for this lovely coercion feature.

stelcheck · 2015-03-20T02:53:39Z

Just a wild thought, but why not turn a bug into a feature?

var folder = 'abc'
path.dirname(['some', folder, 'path'])
// some/abc/path

The currently reported case would remain valid, and array with more than one value would now also work. Thoughts? Stupid or a good idea?

RnbWd · 2015-03-20T03:03:19Z

@domenic and @feross make good points - breaking compatibility with existing modules should only happen in extreme cases. However, using path.dirname(undefined) makes no sense and is probably a programming error. I see no harm in warning people about it (without any intention of changing the API).

rauchg · 2015-03-20T04:05:45Z

iojs shouldn't break existing code this easily.

It'd be better to provide type annotations to avoid such usage at compile time (eg: Flow, TypeScript) moving forward. This is also a more elegant way to trigger warnings of deprecation than console.warns (which can introduce subtle breakage by making hot codepaths slow).

And of course, most importantly, it wouldn't break existing code.

aredridel · 2015-03-20T15:09:29Z

krakenjs/localizr was broken by this too, surprisingly!

brendanashworth added confirmed-bug Issues with confirmed bugs. path Issues and PRs related to the path subsystem. labels Mar 20, 2015

rvagg mentioned this issue Mar 20, 2015

Release proposal: v1.6.1 #1212

Closed

cjihrig mentioned this issue Mar 20, 2015

path: reduce type checking on some methods #1216

Closed

cjihrig closed this as completed Mar 20, 2015

feross added a commit to webtorrent/create-torrent that referenced this issue Mar 20, 2015

fix iojs 1.6.0 issue

2a0500d

nodejs/node#1215

bajtos mentioned this issue Mar 20, 2015

Detect 3rd-party changes made during replication strongloop/loopback#1214

Merged

cjihrig mentioned this issue Apr 9, 2015

Policy on Edge Case Breaking Changes nodejs/dev-policy#37

Closed

cjihrig mentioned this issue Mar 25, 2016

path: assert inputs are strings #5348

Closed

ilkkao mentioned this issue Jul 26, 2016

path.join() doesn't allow array parameter in Node 6 koajs/koa-hbs#52

Closed

This was referenced Dec 1, 2023

[Snyk] Fix for 1 vulnerabilities aliscco/alisco-node#958

Open

[Snyk] Fix for 1 vulnerabilities aliscco/alisco-node#989

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

path: iojs@1.6.0 breaks compatibility with previous versions #1215

path: iojs@1.6.0 breaks compatibility with previous versions #1215

feross commented Mar 20, 2015

rvagg commented Mar 20, 2015

cjihrig commented Mar 20, 2015

rvagg commented Mar 20, 2015

cjihrig commented Mar 20, 2015

rvagg commented Mar 20, 2015

rvagg commented Mar 20, 2015

johnsoftek commented Mar 20, 2015

feross commented Mar 20, 2015

feross commented Mar 20, 2015

cjihrig commented Mar 20, 2015

rvagg commented Mar 20, 2015

cjihrig commented Mar 20, 2015

silverwind commented Mar 20, 2015

monsanto commented Mar 20, 2015

cjihrig commented Mar 20, 2015

RnbWd commented Mar 20, 2015

feross commented Mar 20, 2015

domenic commented Mar 20, 2015

feross commented Mar 20, 2015

cjihrig commented Mar 20, 2015

cjihrig commented Mar 20, 2015

feross commented Mar 20, 2015

xaka commented Mar 20, 2015

domenic commented Mar 20, 2015

silverwind commented Mar 20, 2015

stelcheck commented Mar 20, 2015

RnbWd commented Mar 20, 2015

rauchg commented Mar 20, 2015

aredridel commented Mar 20, 2015

path: iojs@1.6.0 breaks compatibility with previous versions #1215

path: iojs@1.6.0 breaks compatibility with previous versions #1215

Comments

feross commented Mar 20, 2015

rvagg commented Mar 20, 2015

cjihrig commented Mar 20, 2015

rvagg commented Mar 20, 2015

cjihrig commented Mar 20, 2015

rvagg commented Mar 20, 2015

rvagg commented Mar 20, 2015

johnsoftek commented Mar 20, 2015

feross commented Mar 20, 2015

feross commented Mar 20, 2015

cjihrig commented Mar 20, 2015

rvagg commented Mar 20, 2015

cjihrig commented Mar 20, 2015

silverwind commented Mar 20, 2015

monsanto commented Mar 20, 2015

cjihrig commented Mar 20, 2015

RnbWd commented Mar 20, 2015

feross commented Mar 20, 2015

domenic commented Mar 20, 2015

feross commented Mar 20, 2015

cjihrig commented Mar 20, 2015

cjihrig commented Mar 20, 2015

feross commented Mar 20, 2015

xaka commented Mar 20, 2015

domenic commented Mar 20, 2015

silverwind commented Mar 20, 2015

stelcheck commented Mar 20, 2015

RnbWd commented Mar 20, 2015

rauchg commented Mar 20, 2015

aredridel commented Mar 20, 2015