User talk:Evad37/Script modules
This is a subpage of Evad37's talk page, where you can send them messages and comments. |
|
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)
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)
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)
- 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)
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)
- @Deryck Chan: fyi blocked users can't edit their own common.js, etc --DannyS712 (talk) 20:19, 26 January 2019 (UTC)
- ...therefore the issue of blocked users is irrelevant to my question about whether a pseudo-namespace is necessary. Deryck C. 20:22, 26 January 2019 (UTC)
- @Deryck Chan: Sorry, I misunderstood your question. I read
expecting where we want to block a normal user from
as "expecting where blocked users would be..." or something like that. But, what do you mean byprevent users from loading the rest of the MediaWiki namespace into their user scripts
? I'm confused by what you are referring to... --DannyS712 (talk) 20:29, 26 January 2019 (UTC)- @DannyS712: In Evad37's description, the reason for having a pseudo-namespace is so that interface admins can constrain what scripts can be loaded into user scripts and what scripts can't. Why do we want to stop users from loading MediaWiki namespace scripts in general, given that all of them have been reviewed by IAdmins? Deryck C. 20:32, 26 January 2019 (UTC)
- @Deryck Chan: I didn't know that we stop that... maybe because the MW namespace in general is for fully fledged scripts/gadgets/skins, etc, while this would be for reusable components? --DannyS712 (talk) 20:39, 26 January 2019 (UTC)
- @DannyS712: In Evad37's description, the reason for having a pseudo-namespace is so that interface admins can constrain what scripts can be loaded into user scripts and what scripts can't. Why do we want to stop users from loading MediaWiki namespace scripts in general, given that all of them have been reviewed by IAdmins? Deryck C. 20:32, 26 January 2019 (UTC)
- @Deryck Chan: Sorry, I misunderstood your question. I read
- ...therefore the issue of blocked users is irrelevant to my question about whether a pseudo-namespace is necessary. Deryck C. 20:22, 26 January 2019 (UTC)
- @Deryck Chan:
the review process for them are the same as other global scripts in technical terms
– the review process is meant to be a very low bar to cross, basically just "not evil", as opposed to gadgets which have more criteria and require a proposal to gather consensus.It seems that the purpose here is to prevent users from loading the rest of the MediaWiki namespace into their user scripts
– The purpose is to only allow script modules to be loaded using Window.importScriptModule. Other types of MediaWiki scripts can be loaded using conventional means, such as how XFDcloser has aimportScript('MediaWiki:Gadget-morebits.js');
line, and later on usesnew Morebits.simpleWindow(
...etc... .What use cases are you expecting where we want to block a normal user from loading a sitewide script into their own user script?
– When using Window.importScriptModule is going to return a rejected promise, because you tried to load a random script that doesn't use theWindow.exportScriptModule('
syntaxname
',IIFE
);Why do we want to stop users from loading MediaWiki namespace scripts in general, given that all of them have been reviewed by IAdmins?
– We don't, but only the special script modules using the correct syntax can be imported using Window.importScriptModule. Other scripts have to be imported by other means.
One other benefit of using a pseudo-namespace is making them easy to find using Special:PrefixIndex. And it is similar to gadgets being prefixed by "Gadget-". Plus like Danny just said, this is just for components to be used within other scripts. - Evad37 [talk] 23:15, 26 January 2019 (UTC)- @Evad37 and Deryck Chan: to get a better idea of what this would include, I suggest we combine some examples of snippets that we already reuse individually. See my post above. --DannyS712 (talk) 23:38, 26 January 2019 (UTC)
- Agree. Better to make a copy of User:Evad37/extra.js (or to go one step further, MediaWiki:Gadget-morebits.js) that uses the exprtScriptModule syntax, for the sake of demonstration. SD0001 (talk) 04:39, 27 January 2019 (UTC)
- @SD0001: Yeah, but I don't know how to convert it... --DannyS712 (talk) 05:02, 27 January 2019 (UTC)
- Agree. Better to make a copy of User:Evad37/extra.js (or to go one step further, MediaWiki:Gadget-morebits.js) that uses the exprtScriptModule syntax, for the sake of demonstration. SD0001 (talk) 04:39, 27 January 2019 (UTC)
- @Evad37 and Deryck Chan: to get a better idea of what this would include, I suggest we combine some examples of snippets that we already reuse individually. See my post above. --DannyS712 (talk) 23:38, 26 January 2019 (UTC)