User talk:Evad37/Script modules

This is a subpage of Evad37's talk page, where you can send them messages and comments.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Possible extension: Version control

Script module importation could be extended to include version control. This would necessitate each script module having an associated json page mapping version numbers to old revision ids. The importScriptModule function, if given a version number as a second parameter, could first import the script module's json page, and add the oldid= parameter with the appropriate value to the url for loading the script. There should be a way of specifying partial version numbers, and/or greater-than/less-than a version number, similar to how npm does it. The exportScriptModule function would also need to know the version number, and store the exported function/object at Window.exportScriptModule[name][version]. Perhaps the json pages could be maintained by bot. - Evad37 [talk] 03:02, 26 January 2019 (UTC)[reply]

Start collecting

Regardless of if this is implemented or not, it would be useful to have a collection of such "script modules" (if implemented, they form the basis of the "namespace," and if not, they could still serve its purpose). Accordingly, if anyone has a script that they want to add, please post it here (I'll think of a better system soon) so that we can keep track of them. Thanks, --DannyS712 (talk) 04:44, 26 January 2019 (UTC)[reply]

Comments

I think this is a good idea, but have a couple of points:

With the existing syntax, I make out that not just functions, even classes can be exported? If so, that's awesome.
Perhaps you could extend the syntax to match that of mw.loader.using, allowing multiple imports to be declared in an array, so that $.when need not be used?
Is it necessary to restrict the import of scripts to the ones stored in the mediawiki namespace? While it does improve security, I don't that's a very big consideration since till now there hasn't been a single attack that vandalised the mediawiki space (right?). Most people are not interface admins. It would help people to maintain their script-modules if they aren't stored in mediawiki space.

SD0001 (talk) 05:41, 26 January 2019 (UTC)[reply]

Yes, anything that javascript can return can be exported (except undefined, but there wouldn't be much point in exporting that)
Yeah, that should be easy enough to do. Will take a look at coding it tomorrow.
I think there have been cases of malicious code being inserted into the sitewide common.js on other wikis by comprised admin accounts, which is part of the reason interface admins were introduced. Requiring an edit request and a quick check by an int-admin doesn't seem too much of a burdern, especially since this check is explicitly not a full code review. I expect most proposed edits will probably just be rubber-stamped, hence the comment about them not being much better than the average userscript. The other advantage of requiring int-admins to make the edits is that the syntax (single call to Window.exportScriptModule, all module code within the IIFE) is more likely to be enforced / less likely to be inadvertently broken.

- Evad37 [talk] 06:36, 26 January 2019 (UTC)[reply]

Pseudo-namespace

I find it interesting that you want to create a pseudo-namespace for these script modules, when the review process for them are the same as other global scripts in technical terms. It seems that the purpose here is to prevent users from loading the rest of the MediaWiki namespace into their user scripts. What use cases are you expecting where we want to block a normal user from loading a sitewide script into their own user script? Deryck C. 19:56, 26 January 2019 (UTC)[reply]

@Deryck Chan: fyi blocked users can't edit their own common.js, etc --DannyS712 (talk) 20:19, 26 January 2019 (UTC)[reply]