-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Fix: Fix numeric versions resolving to local files #4088
Changes from all commits
bd9ef25
8516fd3
4009e62
5d68a52
eb93c50
9b83d3f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,18 @@ | ||
// Jest Snapshot v1, https://goo.gl/fbAQLP | ||
|
||
exports[`install-file-as-default-no-semver 1`] = ` | ||
"{ | ||
\\"author\\": \\"AJ ONeal <coolaj86@gmail.com> (http://coolaj86.info)\\", | ||
\\"name\\": \\"foo\\", | ||
\\"description\\": \\"A test module with no \`main\`, \`lib\`, or \`dependencies\` specified\\", | ||
\\"version\\": \\"1.0.0\\", | ||
\\"repository\\": { | ||
\\"type\\": \\"git\\", | ||
\\"url\\": \\"git://github.com/coolaj86/node-pakman.git\\" | ||
}, | ||
\\"engines\\": { | ||
\\"node\\": \\">= v0.2\\" | ||
} | ||
} | ||
" | ||
`; |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
{ | ||
"dependencies": { | ||
"foo": "bar" | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
foobar; |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
{ | ||
"name": "1", | ||
"version": "0.0.0", | ||
"main": "index.js" | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
{ | ||
"dependencies": { | ||
"foo": "1" | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY. | ||
# yarn lockfile v1 | ||
"foo@file:bar": | ||
version "0.0.0" |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -134,14 +134,20 @@ export default class PackageRequest { | |
|
||
async normalizeRange(pattern: string): Promise<string> { | ||
if (pattern.indexOf(':') > -1 || pattern.indexOf('@') > -1 || getExoticResolver(pattern)) { | ||
return Promise.resolve(pattern); | ||
return pattern; | ||
} | ||
|
||
if (await fs.exists(path.join(this.config.cwd, pattern))) { | ||
return Promise.resolve(`file:${pattern}`); | ||
if (!semver.validRange(pattern)) { | ||
try { | ||
if ((await fs.stat(path.join(this.config.cwd, pattern))).isDirectory()) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure this check is the right one:
WDYT? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there something preventing us from just fallbacking to the filesystem if the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Don't know if NPM supports tarballs. I'm fine with adding a bit more checks. My initial approach was a lot stricter actually: read the package.json file and make sure the name matches the wanted package name, hence that extra That said when we try to read a package manifest, we automatically fallback to the directory name as package name. This, combined with NPM being quite liberal about paths, lead to this final approach which just checks if it is a directory and it is not a valid semver range. Awaiting further opinions :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Except for the fact that I find it very dangerous (even this current version), I don't think so. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, here's one: if there's a typo, it would make the error message quite cryptic. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah we shouldn't check that, especially since we have a feature to rename packages, so we might end up installing packages under a different name than their original one.
How so? It seems less dangerous to me, since it means that whatever the filesystem is, Yarn would behave the same way on two different systems. Otherwise, there's a risk it will fallback to fetching the package from different ways if the file doesn't exists, instead of reporting about the missing file. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That being said, I checked on NPM and it seems that they just silently ignore |
||
return `file:${pattern}`; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we warn if this happens? I kinda feel like this file pattern isn't great. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And I'm saying, we should support it, but hint at the user that it's silly. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you be more specific? Do you think we should warn people when they omit the |
||
} | ||
} catch (err) { | ||
// pass | ||
} | ||
} | ||
|
||
return Promise.resolve(pattern); | ||
return pattern; | ||
} | ||
|
||
async normalize(pattern: string): any { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the problem here is
rejects
, Do we use this somewhere else?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is because of that. This was introduced by Jest 20 and @onurtemizkan upgraded flow type definitions and used it in one of his patches.
I think Flow gets confused by how
runInstall
is defined bybind
and cannot determine the output type ofexpect
here.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recommend turning it into an async function and awaiting the expect call. Looks a bit cleaner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cpojer you don't like returning promises from tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not explicitly, no. Turning the function into an async function will implicitly return a promise, which Jest then uses to make the test wait for the promise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright. I'll defer this to a later diff tho since it would require a large number of changes in this file (to be consistent) which are not very related to this particular problem. I know I did the
lockfile: false
changes but it was required to make sure tests were running correctly.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine with me, file it under the post-post-1.0 tag ;P