-
Notifications
You must be signed in to change notification settings - Fork 100
Prior art
Some notes about some other JS dependency managers, and how they did not match the design goals for volo.
This biggest difference is volo's desire to use GitHub as the default code registry.
npm is driven by Node's needs, and the way its module system and ID-to-path resolution is set up, which do not map well to web-based module loading. Specifically:
- npm does not handle single JS file dependencies well.
- npm's use of node_modules, support for global installs does not translate well to browser-based module loading.
- uses a custom registry instead of leveraging GitHub. In particular, this can lead to differing names between the GitHub repo for a project and the npm package name. UglifyJS -> uglify-js being one example
Web-based projects are typically simpler than an node project. Web projects have different IO lookup rules (only one IO lookup), which leads to optimal project and library conventions that are different that node/npm projects. In particular, single JS file installs should just be placed in the root scripts directory.
It is common for web projects to check in specific snapshots of dependencies, and not have native OS compiled artifacts.
It is desirable to be able to point to existing URL locations for builds of single JS files. This is possible in volo via a volo.url property in the package.json.
It may be the case that some of the things that volo does for web projects could be integrated into npm. Hopefully by making sure the browser-based dependency management is solved well without needing to compromise to meet Node's needs will help better inform any cross-pollination effort.
cpm informed some of volo's initial development. It was not used because:
- A simpler, one file install was desirable.
- It uses a custom registry instead of GitHub.
It is hopeful that some work could be reused or coordinated with cpm.
Hopefully all of these projects can coordinate on sharing some common package.json properties, project layouts and idioms. Ideally we could agree on using GitHub as the default registry, but if not, hopefully all have adapters to allow its use.
volo does not have to be the only client tool, but it would be great to have a strong JS-focused solution for web projects that is pushing the use of GitHub as the default registry. There needs to be options for private registries, but hopefully those can be modeled off the GitHub API, and ideally proxy to/cache from GitHub for public shared repos.