Skip to content

Conversation

@jgoz
Copy link
Contributor

@jgoz jgoz commented Jul 27, 2014

Re #128, an empty root passed to util.relative should return aPath as-is. This avoids stripping the leading / off of absolute file paths.

Since we don't know whether the empty string is a URL or a file path, we cannot make an assumption either way and should return the path unmodified.

See webpack/core#5 for context around this fix. Specifically, webpack/core#5 (comment) and webpack/core#5 (comment).

@lydell
Copy link
Contributor

lydell commented Jul 28, 2014

Hmm, perhaps empty strings should be treated as ".", just like in util.join. That would be cleaner. If so, please add tests for "." as well. Moreover, it would be good to have a test using the public API that would break without this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Super minor nitpick: Change rootone into root/one. rootone.js is used in the above line just to make sure that libUtil.relative doesn’t think that it should strip /the/root (since both arguments start with that string), because that would be wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, thanks.

@jgoz
Copy link
Contributor Author

jgoz commented Jul 28, 2014

@lydell

Hmm, perhaps empty strings should be treated as ".", just like in util.join. That would be cleaner

Are you proposing that both util.relative(".", "/foo/bar") and util.relative("", "/foo/bar") should return /foo/bar? This makes logical sense to me, because we have no concept of CWD here, so determining a relative path to an absolute path is not really possible.

Moreover, it would be good to have a test using the public API that would break without this PR

Agreed. The test I added for the empty string would break without this change too.

Re mozilla#128, an empty root passed to util.relative should return 'aPath'
as-is. This avoids stripping the leading '/' off of absolute paths.

This treats root paths of '' and '.' the same.

Root path of '/' will strip the leading '/' from any path.
@jgoz
Copy link
Contributor Author

jgoz commented Jul 28, 2014

@lydell Applied the suggested changes.

The only thing I'm not sure about is this test case. You might argue that it should behave like join and return /the/root/one.js, but this is a weird input combination to pass to relative.

As implemented, using / as the root path will always strip the leading path separator from any supplied path, whether or not the path is absolute. Maybe that consistency is a good thing for these unlikely edge cases.

@fitzgen
Copy link
Contributor

fitzgen commented Jul 28, 2014

Are you proposing that both util.relative(".", "/foo/bar") and util.relative("", "/foo/bar") should return /foo/bar? This makes logical sense to me, because we have no concept of CWD here, so determining a relative path to an absolute path is not really possible.

Yes, definitely.

Reviewing changes now...

@fitzgen
Copy link
Contributor

fitzgen commented Jul 28, 2014

The only thing I'm not sure about is this test case. You might argue that it should behave like join and return /the/root/one.js, but this is a weird input combination to pass to relative.

No, that looks good as-is.

fitzgen added a commit that referenced this pull request Jul 28, 2014
Handle empty root in util.relative
@fitzgen fitzgen merged commit 5c6c2e4 into mozilla:master Jul 28, 2014
@fitzgen
Copy link
Contributor

fitzgen commented Jul 28, 2014

Thanks for the pull request!

@jgoz
Copy link
Contributor Author

jgoz commented Jul 28, 2014

Thanks for the quick turnaround!

@jgoz jgoz deleted the relative-empty branch July 28, 2014 21:53
@sokra
Copy link
Contributor

sokra commented Aug 3, 2014

@fitzgen Could you publish it as 0.1.38? It passes all webpack tests now...

@fitzgen
Copy link
Contributor

fitzgen commented Aug 3, 2014

@sokra done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants