spodr | Manage multi-npm-module projects | Runtime Evironment library

First and foremost, the spodr dependency installation mechnism is for development only. Your production deployments still rely on npm or yarn. spodr can automatically download and install all dependencies of all packages referenced in the entire work area, without relying on external package managers. When doing so, spodr will always download the highest possible matching version declared as a dependency for each module in the entire tree. In that, it drastically differs from how npm and yarn treat a dependency tree, where there is a desire to deduplicate the tree as much as possible and utilize packages, lower on the tree, that have matching semver ranges. spodr doesn't care if there is a matching package, if the declared semver range would allow for a newer version of the dependency. It will then use the newer version at the deeper branch. spodr still massively benefits from deduplication, because it treats the entire work area as a single dependency tree. Additionally, spodr will maintain a package cache local to each work area. This is the cache from where every dependency is linked into the projects. The projects that you would previously link globally are, to maintain their connections, now linked through that cache and don't conflict with modules in other work areas. Once a package is cached, it is never copied. Every package is linked into the respective node_modules folders of each project as required. When providing --pin-roots, spodr ensures that the root project (the one that you have in your work area) is used throughout the entire dependency tree, regardless of any requested semver range. This replaces the previous update --link --linkdep operation, but is far more reliable, as consecutive npm install runs could break node_modules by replacing packages in linked projects. When you don't provide --pin-roots, your root projects are still linked into every location in the dependency tree, where their version matches the requested semver range. This can lead to instances of your root projects being downloaded into the package cache, with versions differing from those in your work area. This commonly happens when you don't have all of your "own" packages in the work area. Usually, you want to provide --pin-roots whenever you install dependencies. This might become the default in the final implementation and will have to be disabled with --no-pin-roots. If you want to ensure you have all the latest versions of all dependencies, you can use --update. spodr will then ask the registry for every package again to see if newer versions are available and use those. You can also just delete parts or the entire package cache at any time and rebuild it from scratch. Note that others features may imply --update, as spodr has a very strong desire to ensure that all packages are always used at the most recent version possible. If you want to prevent a certain package version from being used, utilize version locking. When spodr generates the dependency tree, you can instruct it to replace certain versions of packages with different versions, thus, lock the dependency into a given version. When you lock a version, it will be locked throughout the entire global dependency tree, regardless of the location it exists in. This .spodrlock.json would cause all versions of chai-as-promised to be locked down to version 5.3.0. The versions of eslint and uglify-js would be replaced as well, if they'd match the given version ranges. Multiple version ranges could be defined for a module. A module can request to find a peer dependency in the dependency tree. This means that, while it doesn't directly want to depend on a module, it wants to be able to find a module of the given name and version in the tree. Usually, this is produced by a depending module declaring the dependency itself. This mechanism is controlled through the peerDependencies in the package.json. This mechanism is important to resolve issues in other dependency managers. In spodr, you'd always want every single package to declare every single dependency it has. However, that is not being done, because people usually don't use spodr. When npm or yarn see a peer dependency being declared, they warn you if your package higher up in the tree doesn't depend on the requested package. If the package is depended upon, the package is installed high up in the tree and will be found through module resolution. When spodr sees a peer dependency being declared, it links the best possible version directly into the node_modules of the requesting package. Additionally, peering can be controlled through the .spodrlock.json. This is required when modules blindly assume a specific dependency tree structure and just require() a module by name, even through they neither directly or peer depend on it. This works in other package managers, because they register packages always as high up as possible in the isolated node_modules folder of every single module. spodr doesn't do that for performance reasons. So you have to declare a peering manually to ensure a given module is available as a dependency of another module.
eslint will, in every version found in the tree, declare a dependency to every ESlint plugin (where the module name matches ^eslint-plugin-.*$) in any version that is available. If a plugin is available in multiple versions, the first one found is selected. If that is undesireable, a more specific version map must be defined.
A similar setup is being made for karma, so it can load Karma plugins by name.
Because chai-as-promised can not be used in Karma in later versions, we're peering karma-chai-as-promised with chai-as-promised in version 5.3.0. Note that this can still not lead to the desire result. karma-chai-as-promised has an existing peer dependency configured that is satisfied by any version of chai-as-promised. If that was already resolved, spodr will not replace it, unless you lock down the version through version locking (see above).
karma-mocha in a specific version being used is also peered with mocha to allow it to load the dependency by name.
Packages are always resolved to the highest possible version matching the semver range. This is true for the entire dependency tree.
Packages are never copied, they are linked into node_modules.
Because of 1. and 2., when a module requires another module by name, but the containing package did not declare that package as a dependency, it will never be found. For example: Consider you're using eslint and you tell it to use eslint-plugin-promise, then eslint will require( "eslint-plugin-promise" ), but it will not find it, because eslint-plugin-promise is not a dependency of eslint. spodr resolves this by applying some magic if it detects plugin architectures in the tree. It will then see which packages require both eslint and eslint-plugin-promise and register eslint-plugin-promise as a peer dependency of eslint. In that process, spodr will detect which versions of the plugin and host were used and register the peer only for that combination.
Because of 3., when you use a package that uses a package that uses a plugin, you can run into unexpected version conflicts, which you need to resolve manually. For example: Consider you're using gulp-plugin-eslint, which will read your ESLint configuration and runs eslint for you. However, gulp-plugin-eslint could require a different version (or semver range) of eslint than your project. Then gulp-plugin-eslint would use an eslint that doesn't have eslint-plugin-promise, because that is only linked with the version you are depending on (phew). To resolve this, you can: clone a copy of eslint into your work area and use that throughout the entire work area (--pin-roots) use the exact same semver range for eslint that gulp-plugin-eslint declares.
This also means that, if a package relies on having another package in the tree, but it does not explicitly declare this through a peerDependency, it will not be found.