@grant GM functions from @require'd script

Question

I'm writing a series of Greasemonkey scripts. Those scripts share most of their features, so I thought useful to extract the common features.

In common.js are common features, and they call GM_functions (e.g. GM.xmlHttpRequest). Each userscript @require [...]/common.js

Is there a way to avoid repeating all the metadata in each script.user.js :

// @require      [...]/common.js
// @grant        GM.getResourceText
// @grant        GM.xmlHttpRequest
// @grant        GM.setValue
// @grant        GM.getValue
// @connect      localhost
// @resource     styleSheet [...]/style.css

?

I tried to @grant in common.js (or by calling it common.user.js), but it seems like Greasemonkey ignores it anyway.

I understand this can be considered a security flaw, because you may not know what privileges you end up granting because of the @require's cascading @grants. However Greasemonkey could logically infer the final privileges from all the @required scripts.

I have the same question for @resource.

Answer 1

This is unlikely to ever happen.

1. There is very little demand for it.
2. There is even less need for it.

3. It would be a huge security headache:

   1. The various engines already struggle with alerting the user about what evil things a script is trying to do -- and most users ignore it anyway.
   2. Making sure that a previously good @required file didn't break bad. Most engines and scripts do not even check subsource integrity (hash) in the first place. This would be ten times worse if @requires could alter metadata.
   3. Just determining what the final permissions could be would be a challenge. All of the usercript engines have more important/urgent things to code before that.

I understand the desire to code in a modular and DRY way, but superpowered @require files are not the answer.

---

You can probably setup your build environment (EG Git) to automatically add @grants for certain @required files when it assembles the final .user.js file.

If you don't have such a build/source tracking environment, then you are courting disaster with superpowered (or any) modules anyway.