[Suggestion] Drop support for bower

[stof]

Currently, we have to maintain the chosen-package repository to have a git repo friendly to bower. However, bower itself is deprecated in favor of yarn (and so the npm ecosystem): https://bower.io/

Supporting npm/yarn does not require the chosen-package repo (as the code gets published to the npm registry), so this would simplify our infrastructure. what do you think ?

[tjschuck]

https://bower.io/ itself even says to move to Yarn/Webpack, so that does seem to be the better way to go moving forward.

Is there any way we can tell the current usage of the https://github.com/harvesthq/chosen-package repo? Probably not, right?

[koenpunt]

I think we can add a deprecation message to the bower package, do a final release for bower, and then remove the code associated with bower from the repo

[koenpunt]

You might even want to do that release manually

[stof]

https://github.com/harvesthq/chosen-package/graphs/traffic tells me we have a few hundred git clones per day on the packaging repo. This seems big to me, given that Bower should be using tarballs most of the time rather than git clones. I don't think Github gives us any stats about the downloading of archives (unless they are counted as clones too, which would then explain the numbers).

[adunkman]

I’m all for it — our automated scripts aren’t actually working very well (I’ve had to manually do some steps the last few releases). Part of that is because our npm account is now using two factor authentication — we’ll just have to do a little rethinking on how the process is run to get automation working again (a perfect time to drop support for bower).

[tjschuck]

https://github.com/harvesthq/chosen-package/graphs/traffic tells me we have a few hundred git clones per day on the packaging repo. This seems big to me, given that Bower should be using tarballs most of the time rather than git clones.

I'm also super surprised by the number of alleged clones on https://github.com/harvesthq/chosen-package/graphs/traffic if that latter sentence is true, but just poking around, it seems like it might not be...

First of all, our bower.json only specifies a "repository" of type "git", not anything specifically related to Github or it's Releases feature, so that right away makes me think it's probably getting it via a clone of the repo.

The docs for registering a package on bower are very specific about using git tags for versions and putting the package at a "publically available at a Git endpoint", so more "git clone" smell.

Lastly, the language in the output of bower install chosen feels "git clone"-y, not "tarball from releases"-y:

$ bower install chosen
bower chosen#*              not-cached https://github.com/harvesthq/bower-chosen.git#*
bower chosen#*                 resolve https://github.com/harvesthq/bower-chosen.git#*
bower chosen#*                checkout v1.8.3
bower chosen#*                resolved https://github.com/harvesthq/bower-chosen.git#1.8.3

It looks like bower install does support specifying a tarball URL (e.g. bower install http://example.com/package.tar), but anyone just doing bower install chosen is probably doing a git clone from Github, so my feeling is that https://github.com/harvesthq/chosen-package/graphs/traffic is probably a reasonably sound proxy for usage of this repo.

Anyway, all that is to say that it seems like there are a few hundred bower install chosens per day, which makes me feel less inclined to deprecate this.

https://github.com/harvesthq/chosen-package also says it exists for NPM purposes — @stof @koenpunt @adunkman is that not actually true/necessary? Are those clone numbers coming from a mix of bower and NPM usage, and that's why they're higher than expected?

[adunkman]

https://github.com/harvesthq/chosen-package also says it exists for NPM purposes — @stof @koenpunt @adunkman is that not actually true/necessary?

Yeah, that’s not true — npm hosts a tarball that’s used for installs (for example: https://registry.npmjs.org/chosen-js/-/chosen-js-1.8.2.tgz). It’s automatically uploaded when publishing a package version.

Are those clone numbers coming from a mix of bower and NPM usage, and that's why they're higher than expected?

Perhaps someone’s bypassed the npm registry and is installing via git clone of our repository… but I can’t imagine why. It’s technically possible, though!

[tobybellwood]

Chiming in late - the volume of bower users could be Drupal 8 users consuming the library via asset-packagist?

On that note - the bower registry (https://registry.bower.io/packages/chosen) is reporting

{ "name": "chosen", "url": "https://github.com/harvesthq/bower-chosen.git" }

Any chance of getting the registry updated to the chosen-package repo - it's playing havoc with the Drupal whitelist (https://www.drupal.org/packaging-whitelist?title=chosen)?