Sub-dependency handling

[guybedford]

If I have a package.json:

{
  "volo": {
    "dependencies": {
      "mymodule": "my/module"
    }
  }
}

Where "my/module" has package.json:

{
  "volo": {
    "dependencies": {
      "some": "dep/module"
    }
  }
}

Then if I do volo add my/module, the dependency dep/module gets built into the core package.json when it was only ever part of the sub dependency. Ideally these shouldn't get added in to the package.json to keep it only to first level dependencies.

The second issue is that if my package.json does look like:

{
  "volo": {
    "dependencies": {
      "mymodule": "my/module",
      "some": "dep/module"
    }
  }
}

where dep/module is also in my/module, it seems to download the dep/module twice during the same volo create / volo add operation. Ideally this should also be avoided as I have quite a few dependencies that double up in this way, which would immediately cut down a lot of download time.

[jrburke]

I'm having a little trouble visualizing. Maybe something more concrete I could try out?

What first comes to mind: the stamping of a package.json was done for app-level use -- since it is bad on the web to have nested dependencies that may conflict (for download/complexity reasons), the idea was to have the dependencies be flat. If the developer did want two versions of a lib, it is supportable, by installing it under a different local name and setting up a requirejs map config.

This case sounds though like you have a library that could be used in an app, but that library also has dependencies, and the installation of those dependencies is what is causing the problem?

[guybedford]

You've summarised it exactly in the last paragraph. From a user perspective, my expected behaviour is that the library dependencies should install without modifying the base package.json. When there's a folder name conflict, then it could issue a prompt.

Ideally version checking would also be performed as well to resolve duplicates. As at the moment it seems to redownload the library dependencies.

For example, see something like guybedford/selector. This has a dependency on guybedford/require-is. If selector is installed in a project with an existing copy of require-is, it seems to download require-is again. The pacage.json then becomes the flat package.json of all dependencies.

[jrburke]

I tried to reproduce the problem of duplicate downloads by creating a library that had this in its package.json:

{
  "volo": {
    "type": "directory",
    "dependencies": {
      "require-is": "guybedford/require-is",
      "selector": "guybedford/selector"
    }
  }
}

but with volo master (and I suspect with latest released version 0.2.10), there was not a duplicate download for require-is in the second call. If you have a test case I can try the reproduces the duplicate download, that would be good to know.

As for the flat listing in the project's package.json, this is by design: this allows for the resolution of version conflicts, particularly with single JS file installs. So, it is like the master database for items installed in the repo.

While it may seem odd at first, I think it is similar to, for example, amd systems use a config block at the app level to find everything, vs. node/npm's nested directory scanning. If you see a problem where that approach breaks down though, it would be good to explore that more.

Going to close for now as things seem to be working for me, but we can reopen if you have a test case for failure. The "keeping all dependencies in the package.json" may be best explored as a separate ticket though if you find issues with it.

[guybedford]

Yes the duplicate downloading seems to be fixed. Could it have been some quirk to do with the endpoints not matching between the versions? Eg if one module expected require-is to be 0.0.1 and another to be 0.0.2?

Yes it seems I was just complaining... a flat package.json is exactly what I implemented in jspm!

[jrburke]

For version mismatches, it should just warn that there is a mismatch and skip the second one, but printing instructions on how the user can override with a -f command.