`esy resolve`

[yunxing]

For complied languages, we really want a package resolver that has two features:

• By default, resolver should resolve constraints to a single version. This is needed so that the linker is not confused about which object to link with. For example, consider the following case:

  a project A depends on B and C
  B depends on D>= 0.0.1
  C depends on D = 0.0.1
  D has two versions, 0.0.1 and 0.0.2

  The resolver should think hard and pick D@0.0.1 for both B and C.

• On the other hand, we need the notion of "build time" dependency, which allows multiple packages to coexist. Consider the following case:

  a project A depends on B and C
  B depends on D = 0.0.2
  C depends on D = 0.0.1
  D has two versions, 0.0.1 and 0.0.2, and is marked as "build Time dependency" 

  The resolver should pick both versions of D, and create a disk structure like:

  A/node_modules/B/node_modules/D@0.0.2
  A/node_modules/C/node_modules/D@0.0.1

Unfortunately, at this moment both npm and yarn don't support a smart resolver like this: https://github.com/yarnpkg/yarn/issues/579.

What we can do in esy is read the constraints listed in 'package.json' file, and use our customized resolver to generate a yarn.lock or shrinkwrap file. After a file is generated, we can then delegate to yarn or npm to fetch the dependencies for us, and then call esy build to build the dependencies.

With esy resolve and esy build, first time users should be able to just work on the layer of esy, without knowing much details about yarn / npm.

[yunxing]

Some references: https://research.swtch.com/version-sat https://www.npmjs.com/package/logic-solver

[yunxing]

cc @hcarty @yutongp who showed interests in this problem before.