Metadata Block Parsing & Implementing

[stuartpb]

It looks like BabelExt is missing functions for handling userscripts the way GreaseMonkey did.

The way I see it, this could best be accomplished, in an appropriately DIY fashion, by providing:

• A function that takes a string (or something that implements its interface like Node's Buffer), finds the first metadata block (or all? pretty sure successive blocks are ignored), and returns a JS Object with the "@keys" converted to properties of the object, with strings as values (or arrays of strings when there is more than one instance of a key such as @require). This function can then be used by eg. a build script that reads all files, then outputs a "userscripts.json" that will be read in at runtime to determine which scripts to include.
• A function for reading the extension's files (per the above note about using a "userscripts.json").
• A function that takes an object with keys of userscript filenames, and values of the parsed metadata block objects, and then loads the userscripts based on their metadata. This includes per-browser functions (which could be surfaced to the BabelExt API) that add a script (from the extension or from the Internet via @require) in a new context (eg. XPCNativeWrapper in FF, with access to unsafeWindow) either before or after pageload. It can also insert https://github.com/honestbleeps/BabelExt/blob/master/lib/extension.js#L44-51 and/or extension API functions based on @grant.

[honestbleeps]

to be honest I was considering removing all reference to Greasemonkey stuff and greasmonkey shim functions because it's just not really necessary anymore now that the browsers' extension frameworks have matured pretty well.

are there some examples of places where you want/need this metadata and it would be beneficial for BabelExt to handle dealing with it rather than merely loading the scripts via your manifest, etc?

note that unsafeWindow is impossible to access in some browsers no matter what - it's Firefox specific I am pretty sure - and BabelExt needs any functionality it provides to work across all browsers.

I hope I'm not sounding overly critical of the suggestion, I'm just looking to understand the use case - I appreciate any/all commentary and contributions!

[stuartpb]

are there some examples of places where you want/need this metadata and it would be beneficial for BabelExt to handle dealing with it rather than merely loading the scripts via your manifest, etc?

It lets userscripts for an Enhancement Suite-type extension still be developed as userscripts, allowing users who prefer to cherrypick/tweak their scripts to (continue to) do so using GreaseMonkey/TamperMonkey.

As for using this metadata at runtime rather than loading them via manifest etc, it's possible for an extension to have many different scripts that only apply to a few pages. Only importing these scripts when they are meant to apply allows extensions to keep their cross-site loaded footprint small and fast. Reusing the existing GM metadata block has the benefit of already being an established standard, one that can be read directly from the code without having to include/compile/run it, and one that permits standalone development (as mentioned above).

[honestbleeps]

an interesting use case, but pretty specific.

so the core idea here is to avoid having to update/edit multiple manifests, correct?

Only importing these scripts when they are meant to apply allows extensions to keep their cross-site loaded footprint small and fast.

Yes and no. In chrome you're going to have to request access to all websites on the internet, possibly, unless all of the @include or @match (and @exclude for that matter) directives in the GM metadata are for the same domain. That's going to put up a pretty scary/nasty warning message to those who install your extension.

It's an interesting proposal, no doubt, I'm just not sure how wide the audience is for it. I don't see a lot of advantages here considering the amount of code that needs to be written / tested for what it "saves" you in effort of updating manifests on your own, aside from maybe handling the match/include/exclude logic for you?

I do apologize if I'm missing something, I'm reading/responding in the middle of the workday on little breaks here and there.

[stuartpb]

so the core idea here is to avoid having to update/edit multiple manifests, correct?

No, it's to make it so that going to, for example, https://github.com/isaacs/github/issues/new (in a GitHub enhancement suite with 48 userscripts, 3 of which apply to Issues) loads 3 userscripts, instead of 48.

These manifests would be applied and evaluated underneath the top-level extension manifest, which would still be configured for whatever pattern(s) will cover all extension pages. (so Chrome loads only the loader for all of https://github.com/*, and then that loader loads scripts that load on https://github.com/*/*/new/* only on pages that match the pattern.)

Yes and no. In chrome you're going to have to request access to all websites on the internet, possibly, unless all of the @include or @match (and @exclude for that matter) directives in the GM metadata are for the same domain.

"all of the @include or @match (and @exclude for that matter) directives in the GM metadata are for the same domain" is a pretty common case for Enhancement Suite-style extensions that bundle a number of UserScripts for the same site (a fairly wide overlap with the audiences for BabelExt).