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

Fix: Don't do range collapsing when using a frozen lockfile #3604

Merged
merged 4 commits into from
Jun 8, 2017
Merged

Fix: Don't do range collapsing when using a frozen lockfile #3604

merged 4 commits into from
Jun 8, 2017

Conversation

BYK
Copy link
Member

@BYK BYK commented Jun 7, 2017

Summary

Fixes #3313.

Yarn automatically optimizes less-than-ideal yarn.lock files, usually from older versions. That said when run with the --frozen-lockfile argument, it should neither touch the lockfile nor throw an exception if the lockfile satisfies all the needs, even if it can be optimized.

Test plan

Existing unit tests plus a new unit test which fails without the fix applied.

@@ -280,7 +280,7 @@ export class Import extends Install {
if (manifest.name && this.resolver instanceof ImportPackageResolver) {
this.resolver.rootName = manifest.name;
}
await this.resolver.init(requests, this.flags.flat);
await this.resolver.init(requests, this.flags.flat, this.flags.frozenLockfile);
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we change this to named args, like this:

this.resolver.init(requests, {
  flat: this.flags.flat,
  frozenLockFile: this.flags.frozenLockfile,
});

?

Copy link
Member

Choose a reason for hiding this comment

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

Dang, this time I've been 28 seconds slower 😆

Copy link
Member Author

Choose a reason for hiding this comment

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

Damn! I actually did it that way first and then went back to this monstrosity :(

Copy link
Member

@arcanis arcanis left a comment

Choose a reason for hiding this comment

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

Good for merge! 😃 However, note that we're trying to get away from boolean traps, so in the future this kind of flag should be passed in a trailing object 👍

@BYK
Copy link
Member Author

BYK commented Jun 8, 2017

@arcanis - Please do not merge until I defuse the boolean trap ;)

async init(deps: DependencyRequestPatterns, isFlat: boolean): Promise<void> {
async init(
deps: DependencyRequestPatterns,
{isFlat, isFrozen}: {isFlat: boolean, isFrozen?: boolean},
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't isFlat be also a isFlat? in its type? I'm not really familiar with Flow, though. On a different note, you can add a default value ( = {} at the end of the parameter declaration) so that you don't have to explicitely pass an empty object (like here). That might require to move the workspaceLayout parameter before the options.

Copy link
Member Author

Choose a reason for hiding this comment

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

Nice! I thought about default params but wasn't sure if we supported them. Since now I know, I'll go ahead and use it.

@@ -15,6 +15,12 @@ import WorkspaceLayout from './workspace-layout.js';
const invariant = require('invariant');
const semver = require('semver');

export type ResolverOptions = {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you make it an exact type using:

export type ResolverOptions = {|
  …
|}

that way you cannot add fields to the object that aren't specified here. In general, I recommend all object type definitions to use this unless they have a good reason not to.

@BYK BYK merged commit 7515772 into yarnpkg:master Jun 8, 2017
@BYK BYK deleted the maintain-integrity branch June 8, 2017 20:26
BYK pushed a commit that referenced this pull request Jun 8, 2017
Follow up to 7515772.

After refactoring #3604 I forgot to remove these empty objects
so now I'm doing it with this diff :)
arcanis pushed a commit that referenced this pull request Jun 9, 2017
Follow up to 7515772.

After refactoring #3604 I forgot to remove these empty objects
so now I'm doing it with this diff :)
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.

The --frozen-lockfile command-line option does not work
3 participants