Create project to aggregate selected userscripts that mitigate things addressed in this issue queue

[patcon]

The aggregated userscript could be loaded into userscripts.org as a bundle.

The benefit of aggregating individual scripts is that it might allow people who disagree with one script to use the source repo and compile their own remix.

Here's a current list of existing candidates:

• PR tag widget - @iguananaut

EDIT: Realized that this would be a lot like Reddit Enhancement Suite (RES), and so found some repos and potential collaborators who were aspiring to that:

• https://github.com/jayson/github-enhancement-suite [@302 @jayson]
• https://github.com/EvanDotPro/github-enhancement-suite [@EvanDotPro]
• https://github.com/mduan/Github-Enhancement-Suite [@mduan]
• https://github.com/rsbrown/ghes [@rsbrown]
• https://github.com/skratchdot/github-enhancement-suite [@skratchdot]

[patcon]

If people see this as a good idea, perhaps we could create a new tag to help identify current issues that could be "fixed" via userscript?

cc: @isaacs

[patcon]

Another thought from here: https://github.com/isaacs/github/issues/38#issuecomment-29644206

We could track analytics comparable to how yeoman's insight tool does it, and provide open data on feature usage: https://github.com/yeoman/insight#readme

[rsbrown]

Great idea.

[jteneycke]

I'm totally in. :thumbsup:

[skratchdot]

I'm definitely up for this. I've been meaning to modularize (and re-do) some of the scripts in this repo:

https://github.com/skratchdot/github-enhancement-suite

It definitely needs on/off switches for the various userscripts. One issue I've ran into with some of my scripts, is they need to be injected onto the page (due to Github's CSP headers: http://skratchdot.com/2013/05/userscripts-and-content-security-policy/ )- so I had to host the scripts on gists.github.com as a hacky workaround.

I'm up for trying to find a better solution though...

[juliettepaul]

I'd definitely be down for this as well. I wrote my script mostly for github enterprise and I've noticed it currently doesn't work on github public. Keeping it working on both has been a pain, but I have been meaning to make my stuff more resilient to updates anyways.

[iguananaut]

I'm not entirely clear on how this would be different from all the other "github enhancement suites" already linked to, except maybe to try to federate them all since they do all do different sets of things and perhaps with different levels of support and workingness. But definitely :+1: in principle!

If I may offer another candidate: http://userscripts.org/scripts/show/178691 This creates links out of the pull request source/targets. I've found it very useful. Not sure if this is already covered by any of the existing suites. // Scratch that, I see that @skratchdot's package provides this feature.

[stuartpb]

I might be up for forking RES, starting with the framework (the one that cross-compiles the extension for Chrome and Firefox) and maybe their UI if it's general enough. Then we'd push it to the Chrome Store / Firefox Addon Whatever as a separate downloadable and installable extension rather than a userscript (to make it more accessible/discoverable by the average user).

Meanwhile, I'm looking at putting a script together for #326, so GitHub userscript authors: is there an easy way to make API calls on behalf of the logged-in user without having to make the user log in to your userscript to generate an auth token?

[stuartpb]

Fuck it, I just set up an org to handle this: https://github.com/ghes (To dodge any trademark violations with the Octocat, the working logo is just one of the first public domain Google Images results for "cyborg cat").

In terms of structure, I'm thinking people can just have repos for whatever enhancement userscripts they want under the org (with gh-pages as their default branch), and then we can have a Chrome / Firefox extension that automatically pulls from these repos to assemble the extension (like a preloaded Tampermonkey).

[patcon]

:+1: @stuartpb :)

[skratchdot]

@stuartpb - I was actually going to re-write/re-work my extension b/c it's pretty outdated now (some of the selectors/features don't even work anymore). I wanted to re-write it using browserify and a plugin-like structure (CommonJS style).

So each feature/plugin would just export a few things that the main framework would know about.

I was thinking something along the lines of:

/plugins/MyPlugin.js:

exports.name = 'some unique name';
exports.description = 'describe what this feature does';
exports.previewImage = '/images/myPreview.png'; // or a full url
exports.pageSelector = 'body.logged_in'; // only activate on pages that match this selector
exports.init = function () {/*implementation*/}; // if pageSelector is matched, and the plugin is enabled, then this is called
exports.settings = {}; // maybe have a way of defining default settings that can be tweaked on a settings page

The main script/framework would handle things like having a "settings" page where you could enable/disable features and see preview images, descriptions, etc. It would also loop through all the plugins calling init() for anything that is enabled by the user, and matches the given pageSelector.

I can probably work on that soon, so let me know if you are interested in collaborating or adding me to that org.

[stuartpb]

I've written another userscript, this time for fixing #248: https://github.com/ghes/contributing-includer

[stuartpb]

@skratchdot - a common set of scripts implemented in one project, shipping in lockstepped versions like RES, does seem like a better solution than my current everything-gets-its-own-repo-and-team gh-pages-as-CDN anarchy.

However, before we go inventing a whole new system, I think it's worth taking a look at how RES is designed as a platform. From there, we either (some of this is obviously non-exclusive):

• Copy Reddit Enhancement Suite's API and (to whatever extent) platform, and package extensions however RES does it
• Copy GreaseMonkey's userscript API, and package extensions as traditional Userscripts compatible with GreaseMonkey/TamperMonkey, and use some layer on top of that to handle an RES-style configurator. (This way users aren't forced to install an extension if they just want a UserScript.)
• Use another cross-browser extension framework (RES does admittedly look kind of thrown together and requires jQuery and stuff, but I honestly don't know another good cross-browser extension platform).
• Invent a whole new platform, with a level (preferably low) of standard platform provided to functions (even if just to expose things like GM_setValue in a browser-agnostic way).
• Just make one big userscript that includes all the others.

Whatever way we go, it should involve a close look at RES first:

https://github.com/honestbleeps/Reddit-Enhancement-Suite

[skratchdot]

@stuartpb - It looks like RES uses BabelExt. There's a few cross platform browser extension frameworks / projects listed on this StackOverflow question: http://stackoverflow.com/questions/4913123/cross-browser-extensions-api

I also see: https://github.com/trigger-corp/browser-extensions

Also took a quick peek at RES, and the way they create modules is pretty similar to what I outlined above: https://github.com/honestbleeps/Reddit-Enhancement-Suite/blob/328ceb7edd8fc4b60679e32fa5c2360b95d887a8/lib/reddit_enhancement_suite.user.js#L130

[stuartpb]

@skratchdot - Hmm. BabelExt looks like a good starting point, but one that can get a little hoary to maintain cross-platform. I'd be up for giving it a shot, though (it beats using a build system that requires Python, Mercurial, and the JRE just to run).

Is that module system, including and compiling everything for every extension on every page, performant enough for RES, and could it be better? I think I'd prefer a format that uses the inclusion data (ideally, from the Metadata Block of the userscript at build time) as static matching patterns, then inserts the userscripts when they would have been inserted by GreaseMonkey/TamperMonkey. (It looks like BabelExt doesn't include a way to insert a script with a safe window context cross-browser, so I don't know how feasible that goal is.)

Also, for maintaining options for extensions, I think a slight layer over BabelExt's storage.get and storage.set that tracks shipping options versions, and does migrations, would be a useful API to provide.

[stuartpb]

The second point in the comment above is being discussed in honestbleeps/BabelExt#23

[embray]

That's sounding like a great idea. The only GitHub enhancement I've written myself is no longer needed, thankfully. But I can think of plenty of others (most of which have issues here) so keep me posted--I'd happily contribute to such a collection. It would be great to ship a bunch of enhancements (presumably with on/off switches) as a single product.

[stuartpb]

Actually, looking at the approach I'm currently taking with Rogueport, I think I'd rather go with continuing to do separate userscripts for each feature, "shipping" them via GitHub Pages, and allowing users to use an extension like TamperMonkey for managing the scripts.

For bundling / cross-platform functionality, we can create a userscript and extensions that do their own, simplified version of TamperMonkey-style management.

As for GitHub APIs and things like that, these are handled from the userscript down, not provided by any external dependency.

[Mottie]

I'd like to throw my table of contents userscript into this mix. It creates a table of contents for wiki pages and readme files as described in #215.

[stuartpb]

@Mottie Interesting - I have some ideas about how I'd like to adopt those https://github.com/Mottie/GitHub-userscripts/ into the @ghes organization (the key difference being that I'd like to git filter-branch each script into its own repository, and then use GitHub Pages on master as the distribution mechanism rather than raw.githubusercontent.com) and/or adopt the https://github.com/Mottie/Octopatcher extension as the kind of one-shot script bundle I described above (though I'm kind of 😕 about it, since it seems like shipping new extension builds for each constituent script update would be a lot of busywork for not a lot of benefit over just letting Tampermonkey handle it) - I definitely think Octopatcher's logo beats the one I currently have for the @ghes organization.

[stuartpb]

As for this:

As for GitHub APIs and things like that, these are handled from the userscript down, not provided by any external dependency.

The one thing that this overlooks is API endpoints that require authorization, which I'm building a structure for right now (handling the tokens will still be in the hands of each individual userscript, but obtaining them will be facilitated by a function provided by a specific page).

[Mottie]

it seems like shipping new extension builds for each constituent script update would be a lot of busywork for not a lot of benefit over just letting Tampermonkey handle it

That's pretty much what is done with https://github.com/sindresorhus/refined-github... there is also an npm module (https://github.com/DrewML/chrome-webstore-upload) to automatically update the Chrome web store, but it won't be as easy for the other browsers' extension updates.

Octopatcher's logo beats the one I currently have for the @ghes organization

Arrgh, I think ye littl' cyborg cat is cute!

[aspiers]

https://github.com/stefanbuck/awesome-browser-extensions-for-github seems relevant here too.