Bower packages and GitHub's new Releases feature

[ericf]

GitHub announced their Releases feature and I think it's something which Bower can leverage.

When I first started using Bower I quickly hit a wall: My project has a build step and I do not want to checkin the build files. I am not alone, this issue and related ones are being discussed at length:

• postinstall script (and others) #249 postinstall script
• Recommended way of fetching repos that require further build? #455 Recommended way of fetching repos that require further build?

Currently, Bower utilizes GitHub and tags as the primary source of truth for metadata about registered Bower packages—and this is great! But, there are now discussions which are pushing Bower away from this and to something closer to npm's registry and packaging model. But we have a chance to do something different and leverage GitHub's new Releases feature!

---

I did a quick investigation to determine if GitHub's API has an endpoints for their Releases feature, and it does. It seems that Bower could be changed to leverage a package's releases first, tags second, since creating a project release allows you to upload a package binary (dist file).

Here's an example using Pure, where I already setup its releases on GitHub:
https://github.com/yui/pure/releases

This information can also be accessed via GitHub's API:

• Releases metadata: https://api.github.com/repos/yui/pure/releases
• A release's assets: https://api.github.com/repos/yui/pure/releases/422/assets

---

Does GitHub's new Releases feature provide an alternative path forward which allows Bower to leverage a project's releases on GitHub as the source of truth for Bower packages?

[jrburke]

What I support in volo is an "url" property in the JSON metadata, and when fetching the metadata for a given release tag, if there is an "url" property, that URL is used as the target download for the installed dependency instead of pulling the repo's zip snapshot. Doing something similar in bower would allow pointing that "url" property to the releases bundle.

[wibblymat]

@ericf we actually support any git server, not just GitHub, so that people can use whatever hosting they like including internal private git servers.

I suppose that we could add an extra code path to check if we are looking at GitHub and use Releases if there are any. We will continue to support the git repo and tags way of doing things in the future even when we also have the npm style registry, so it is entirely feasible. We'd have to be careful that adding more options doesn't make things too complicated or confusing (for users or for us in the code).

[sindresorhus]

I would rather we just wait for the publishing step, like npm publish instead of creating lots of GitHub specific code paths.

[ericf]

I just surveyed the 2788 Bower packages in the main registry and all of them use GitHub.com URLs. I understand that you can setup a private Bower registry, but I assume that's very small percentage of people, and an even smaller percentage of bower install executions.

It also seems likely that adding support for GitHub's Releases feature is a lot smaller and more defined task than setting up the whole npm-style registry system (web service, package hosting, and code refactoring) and it is also a solution to the post-install/build files issues which I feel is currently holding Bower back.

@wibblymat If you and the other Bower maintainers agree that this has legs, I'd love to help further flush out this proposal as well as help with the code changes to Bower to implement it.

[necolas]

They all use GitHub URLs because we only provide a registration option at the moment.

The problem of built assets, authentication, and faster installs will be dealt with by the proven publishing model that's being pursued. Relying on GitHub is not a robust or long-term solution. We can't expect their releases feature to remain stable, or for people running private registries to rely on GitHub for this.

[necolas]

Some info about the registry plans:

Draft spec: https://docs.google.com/document/d/17Nzv7onwsFYQU2ompvzNI9cCBczVHntWMiAn4zDip1w/
Meeting notes: https://github.com/bower/bower/wiki/Meetings

Rest needs to be better exposed as issues on the registry repo now.

[satazor]

While the registry has many advantages over the current url mapping scheme, I saw a potential improvement by using the GitHub tarballs for github endpoints, specially for huge dependencies such as lodash and requirejs that takes too many time to clone (even with --depth and --branch). With the new rewrite architecture, it was really easy and straightforward to implement the GitHub resolver that takes advantage of it. Checkout this issue: #597

Note that I'm not using the GitHub API, or something similar. Instead of cloning, Bower will download and extract the tag tarball.

[paulirish]

In #597 Andre implemented a resolver to grab tarballs from this new feature. Installing lodash went from 37.835s to 8.542s

[ericf]

@satazor #597 will be great for speeding things up and makes a lot of sense to do when someone is installing based on a tag. Does it seem reasonable to you if we take the GitHub Resolver ever further and give it knowledge of tags which are GitHub Releases so that it can instead download the assets associated with a release (which can be different from the source tar ball)?

Doing so would cover what I'm proposing in this issue. I am also willing to add this logic into what you've already started with the GitHub Resolver once that lands. I understand that this could be a wasted effort on my part with the risk of the change not being accepted, but I'm willing to layout a working proposal for this idea of hooking into GitHub Releases.

[eastridge]

@satazor @ericf

Implemented this grunt plugin to help with the issue I was having:

https://github.com/walmartlabs/grunt-release-component

[wilmoore]

As mentioned by @jrburke, the url property is pretty handy in volo and is host agnostic:
https://github.com/wilmoore/selectn/blob/master/package.json#L38

[FezVrasta]

Is it possible to do something like this:

{
  name: "jquery",
  dependencies: {
    "jquery": "https://github.com/jquery/jquery/archive/3.1.1.zip",
  },
  "version": "3.1.1"
}

To make Bower install jquery (or any library) from the GitHub releases zip?