weird behaviour with mnmly/slider

[stephenmathieson]

for some reason, we're fetching the gh-pages branch of mnmly/slider:

$ echo "require('mnmly/slider')" | duo -t js > /dev/null

     building : from stdin
    installed : mnmly-slider@gh-pages
    installed : component-domify@1.3.1
    installed : component-emitter@1.1.3
    installed : gorillatron-extend@master
        built : from stdin

i have absolutely no idea how this could be happening...

[dominicbarnes]

Hmm, just checked out yields/gh-resolve to trace this problem down. Looks like git ls-remote lists off both gh-pages and master respectively. (this repo has no other tags) Since no version defaults to * (not master) and gh-pages is listed first, that means it gets chosen.

How we should handle that is another question altogether, should we prefer master when we have no version? Should we just exclude certain things like gh-pages? (weird to "blacklist" stuff like that though)

[stephenmathieson]

yeah, i think we should default to master if no tags exist.

unrelated: i ended up using your slider instead. good stuff man :+1:

[dominicbarnes]

@stephenmathieson cool deal :)

It's been a while since I did anything with that lib, let me know if you run into any problems.

[dominicbarnes]

Can this be closed now?

[stephenmathieson]

it's still an issue until we release gh-resolve and bump its version in package.json

[dominicbarnes]

I'll do the bump+release dance once I can get duojs/gh-resolve#20 fixed. :)