Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make file: URLs (mostly) RFC 8909 compliant #60

Merged
merged 1 commit into from
Jun 15, 2021

Conversation

isaacs
Copy link
Contributor

@isaacs isaacs commented Jun 15, 2021

The change made in e8c4301 was
reasonable, but had the unfortunate side effect of breaking backwards
compatibility for urls like 'file://.'.

Further investigation showed that we really weren't complying with RFC
8909's specifications regarding file: URLs, and even further
investigation than that showed that it'll be a breaking change if we do.

This patch isolates the non-8909 compliance bits into a single block
that can be disabled with an environment variable and easily removed
when we are willing to take on that breaking change. The bug fixed by
the commit that broke file://. is still fixed, and we obey RFC8909
otherwise.

References

@isaacs isaacs requested a review from nlf June 15, 2021 18:26
@isaacs
Copy link
Contributor Author

isaacs commented Jun 15, 2021

Arguably beneficial side effect of this change: file:///absolute/path gets a fetchSpec of C:\absolute\path on Windows, instead of c:/absolute/path.

@isaacs isaacs force-pushed the isaacs/rfc-8909-compliant branch 2 times, most recently from 92132b3 to 97d2923 Compare June 15, 2021 18:38
res.saveSpec = 'file:' + path.relative(where, res.fetchSpec)
// always put the '/' on where when resolving urls, or else
// file:foo from /path/to/bar goes to /path/to/foo, when we want
// it to be /path/to/foo/bar
Copy link
Contributor

Choose a reason for hiding this comment

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

if using file:foo from /path/to/bar, wouldn't we want it to be /path/to/bar/foo instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, that's what the comment is saying.

Copy link
Contributor

Choose a reason for hiding this comment

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

hahaha no, it says /path/to/foo/bar

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oh, haha, yeah, swapped the parts in the comment. The code is right, though. I'll fix it.

Copy link
Contributor

@ruyadorno ruyadorno left a comment

Choose a reason for hiding this comment

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

LGTM 👍

The change made in e8c4301 (#53) was
reasonable, but had the unfortunate side effect of breaking backwards
compatibility for urls like 'file://.'.

Further investigation showed that we really weren't complying with RFC
8909's specifications regarding file: URLs, and even further
investigation than that showed that it'll be a breaking change if we do.

This patch isolates the non-8909 compliance bits into a single block
that can be disabled with an environment variable and easily removed
when we are willing to take on that breaking change.  The bug fixed by
the commit that broke file://. is still fixed, and we obey RFC8909
otherwise.

PR-URL: #60
Credit: @isaacs
Close: #60
Reviewed-by: @ruyadorno
@isaacs isaacs force-pushed the isaacs/rfc-8909-compliant branch from 97d2923 to 8a6d887 Compare June 15, 2021 19:12
@isaacs isaacs closed this in 8a6d887 Jun 15, 2021
@isaacs isaacs merged commit 8a6d887 into latest Jun 15, 2021
ruyadorno added a commit to ruyadorno/npm-package-arg that referenced this pull request Jun 15, 2021
@lukekarrys lukekarrys deleted the isaacs/rfc-8909-compliant branch October 12, 2022 20:44
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.

2 participants