Less awful front end package management

I know. There are already a ton of package managers out there. I've tried using all of the major ones. Believe me, I've tried to make them work. I don't want another one.

tl;dr: (╯°□°)╯︵ ┻━┻

Gaucho can make things a little better:

  • no manifest file Depending on every library to keep up with all of these is fucking madness, and it's not working! Instead Gaucho provides a list of curated packages at specific versions.
  • much smaller front end packages There's no reason to pull in the entire library's files, many of which are only there to develop on the library itself.
  • no centralized server
  • limited goals Gaucho shares Bower's desire to remain as a low-level solution for solving only the problem of finding, installing, updating, and removing packages.
  • simple command line interface inspired by npm and Bower, it provides a clean, simple command line to manipulate front end packages

the -g option installs the package globally, so you can use gaucho as a command line utility.

Usage: gaucho [options] [command]
    info <pkg>             Version info and description of a particular package
    install <pkg>          Installs a browser package locally into the components directory
    list                   Lists all packages
    ls                     Alias for list
    search [keyword]       Finds all packages or a specific package
    uninstall <pkg>        Uninstalls a browser package locally from your components directory
    remove <pkg>           Alias for uninstall
    -h, --help     output usage information
    -V, --version  output the version number

Right now, the strategy for defining available packages is very simple. Clone the repository, and open up content.json. You'll see a big ole' pile of json that defines the various packages, keyed by package name, then version, then the details on what files to grab. Add your changes, and send me a pull request.

NOTE: everyone hacking away on a single JSON file isn't the best strategy when the package count gets beyond a few hundred. For now it's intentionally kept simple. If this should become unwieldy I'm totally willing to accept a more friendly solution if/when we get there.

There are several ways to declare packages:

These are projects that just have single file in them. They are the easiest to declare. Jquery is an example of a single file package:

"jquery": {
    "2.0.2"  : "",
    "1.10.1" : ""

Each version is basically a string pointing at the fully qualified URL to pull the file from

These projects are a bit more complicated in that they are github repos at a certain commit containing 1 or more files and directories to include. Modernizr is an example of a github based package:

"modernizr": {
    "2.6.2": {
      "location": "",
      "commit": "87c723720a48254ae37ffd56829e32a96f5c5496",
      "paths": [ "modernizr.js", "feature-detects" ]

In the above example, location is the github URL to clone, commit is the hash of the tag for the given release, and paths is a list of files and/or directories associated with the package that are required to make it usable. If the commit field is not specified, it will use HEAD.