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: #38 (comment)

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. 👍

[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 👍 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]

👍 @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.