From 186fa26eff4f6b1b79bc9698c31f892dcd5dc94e Mon Sep 17 00:00:00 2001
From: David Glasser <glasser@meteor.com>
Date: Wed, 10 Sep 2014 19:30:28 -0700
Subject: [PATCH] Don't skip initial constraints with useRCsOK!

Also, we can still calculate topLevelPrereleases since maybe that can be
used for better diagnostics or something
---
 packages/constraint-solver/resolver.js | 50 +++++++++++++-------------
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/packages/constraint-solver/resolver.js b/packages/constraint-solver/resolver.js
index 3b201680eb..a465c9a190 100644
--- a/packages/constraint-solver/resolver.js
+++ b/packages/constraint-solver/resolver.js
@@ -152,33 +152,33 @@ ConstraintSolver.Resolver.prototype.resolve = function (
 
   if (options.useRCs) {
     resolveContext.useRCsOK = true;
-  } else {
-    _.each(constraints, function (constraint) {
-      startState = startState.addConstraint(constraint);
-
-      // Keep track of any top-level constraints that mention a pre-release.
-      // These will be the only pre-release versions that count as "reasonable"
-      // for "any-reasonable" (ie, unconstrained) constraints.
-      //
-      // Why only top-level mentions, and not mentions we find while walking the
-      // graph? The constraint solver assumes that adding a constraint to the
-      // resolver state can't make previously impossible choices now possible.  If
-      // pre-releases mentioned anywhere worked, then applying the constraints
-      // "any reasonable" followed by "1.2.3-rc1" would result in "1.2.3-rc1"
-      // ruled first impossible and then possible again. That's no good, so we
-      // have to fix the meaning based on something at the start.  (We could try
-      // to apply our prerelease-avoidance tactics solely in the cost functions,
-      // but then it becomes a much less strict rule.)
-      if (constraint.version && /-/.test(constraint.version)) {
-        if (!_.has(resolveContext.topLevelPrereleases, constraint.name)) {
-          resolveContext.topLevelPrereleases[constraint.name] = {};
-        }
-        resolveContext.topLevelPrereleases[constraint.name][constraint.version]
-          = true;
-      }
-    });
   }
 
+  _.each(constraints, function (constraint) {
+    startState = startState.addConstraint(constraint);
+
+    // Keep track of any top-level constraints that mention a pre-release.
+    // These will be the only pre-release versions that count as "reasonable"
+    // for "any-reasonable" (ie, unconstrained) constraints.
+    //
+    // Why only top-level mentions, and not mentions we find while walking the
+    // graph? The constraint solver assumes that adding a constraint to the
+    // resolver state can't make previously impossible choices now possible.  If
+    // pre-releases mentioned anywhere worked, then applying the constraints
+    // "any reasonable" followed by "1.2.3-rc1" would result in "1.2.3-rc1"
+    // ruled first impossible and then possible again. That's no good, so we
+    // have to fix the meaning based on something at the start.  (We could try
+    // to apply our prerelease-avoidance tactics solely in the cost functions,
+    // but then it becomes a much less strict rule.)
+    if (constraint.version && /-/.test(constraint.version)) {
+      if (!_.has(resolveContext.topLevelPrereleases, constraint.name)) {
+        resolveContext.topLevelPrereleases[constraint.name] = {};
+      }
+      resolveContext.topLevelPrereleases[constraint.name][constraint.version]
+        = true;
+    }
+  });
+
   _.each(dependencies, function (unitName) {
     startState = startState.addDependency(unitName);
     // Direct dependencies start on higher priority