ied

ied __/\\\\\\\\\\\__/\\\\\\\\\\\\\\\__/\\\\\\\\\\\\____ _\/////\\\///__\/\\\///////////__\/\\\////////\\\__ _____\/\\\_____\/\\\_____________\/\\\______\//\\\_ _____\/\\\_____\/\\\\\\\\\\\_____\/\\\_______\/\\\_ _____\/\\\_____\/\\\///////______\/\\\_______\/\\\_ _____\/\\\_____\/\\\_____________\/\\\_______\/\\\_ _____\/\\\_____\/\\\_____________\/\\\_______/\\\__ __/\\\\\\\\\\\_\/\\\\\\\\\\\\\\\_\/\\\\\\\\\\\\/___ _\///////////__\///////////////__\////////////_____ An alternative package manager for Node. Concurrent Installations - ied installs sub-dependencies in parallel. This means that the download of a dependency might have been completed before that of its parent or any of its siblings even started. Correct Caching - Downloaded packages are being cached locally. Similarly to the entry dependencies stored in node_modules, they are being identified by their checksums. Therefore we can guarantee the consistency of the cache itself without (manually) invalidating dependencies (e.g. due to overridden version numbers). node_modules as CAS - Packages are always being referenced by their SHA-1 checksums. Therefore a node_modules directory can be considered to be a Content Addressable Storage, meaning that packages are being identified by their contents, not by arbitrary identifiers, such as package names that are not guaranteed to be unique across different registries. Flat node_modules - Due to the CAS-based design, conflicts due to naming collisions are more or less impossible. Therefore all dependencies can be stored in a flat directory structure. Circular dependencies and dependencies on different versions of the same packages are still being handled correctly. Guaranteed uniqueness - Since the directory in which a specific package is being stored is determined by its shasum, identical packages can't conflict due to their location in the file system itself. This also means that the same dependency won't be installed more than once. Dependencies don't need to be explicitly declared as peerDependencies, since shared sub-dependencies are the default, not an option. Atomic installs - The atomicity of installs can be ensured on a package-level. "In progress" downloads are being stored in node_modules/.tmp and moved into node_modules once their download has been completed. In order to prevent deadlocks, packages that have circular dependencies are exempt from this limitation. In most cases however, the node_modules directory is consistent at any given point in time during the main installation procedure. Package names as links - While packages are being referenced by their shasum internally, they can still be required via their human-readable equivalent name. Package names themselves are simply symbolic links to the actual content-addressed package itself. A nice side-effect of this design is that in contrast to other package managers, you can not accidentally require a sub-dependency that hasn't been installed as such. Semantic Versioning - Semantic version numbers are being resolved correctly. Arbitrary package groups - Packages can be grouped into "package groups", such as dependencies and devDependencies. Dependencies can be installed exclusively based on the group they are in. Internals Under the hood, ied maintains an "object database", similar to git. Instead of storing packages by some arbitrary name, a SHA1-checksum is being generated to approximate their contents. The checksums can not only be used for guaranteeing a certain level of trust and consistency, but they also simplify the algorithm through which dependencies are being managed. The algorithm through which packages are being installed guarantees consistency through atomic installs. The installation of a package either fails or succeeds, but at no point in time can a dependency itself be required without having its own sub-dependencies installed (with the exception of shared circular dependencies). The checksum of a package is based on the contents of the package itself, not of its sub-dependencies. Therefore the validity of a package can be verified by hashing the package itself. Subsequent dependency updates have no effect of the generated checksum. Since node_modules is essentially a file-system based content addressable storage, multiple versions of the same package can co-exist in the same project. In order to expose dependencies via CommonJS, symbolic links are being created that reference a specific version of the package. This has multiple advantages: Undeclared dependencies that have been installed as sub-dependencies of "direct" dependencies are unlikely to be required "accidentally". There is no need to "manually" (as in additionally to the installation procedure itself) de-duplicate the dependency graph. As long as the uniqueness of filenames itself can be guaranteed on an OS-level, it is impossible to install the same package twice. This does not prevent users from installing different versions of the same dependency as long as the content is different (whereas a different version declared in the package.json counts as different contents). Shorter pathnames and less problems due to OS-level limitations (as in Windows where the maximum path length is limited). Additional application-level startup performance improvements. require needs to traverse less directories. A limited number of symbolic links need to be followed. This performance improvement is primarily useful for continuously running tests, where startup time is actually noticeable for larger test suits. Directory Structure The used directory structure is primarily optimized for reducing the amount of IO interaction with the file system during subsequent installations and guaranteeing the consistency of installed packages. A consequence of the require.resolve algorithm used by Node, all packages need to be stored in a project-level node_modules directory. This directory is completel