Change Details

I have some scripts, some of which are Gadgets, that depend on "library" scripts. For example, say I have user-script "Tool A" and gadgets "Gadget A" and Gadget B" that all depend on "Library A", which hangs its API from `window.LibraryA`. Library A is a Gadget too, so I can load it with `mw.loader.using("ext.gadget.LibraryA")`. However, when I am developing Tool A, I may want to also adjust Library A. Normally, I serve the JS locally for development, so I use something like `mw.loader.load("https://localhost/libraryA.js")`. This means that if I have Gadgets A and B enabled, I'll be loading two copies of Library A, one from the wiki and one locally, which will compete for the `window` slot. So I have to hack in guards somewhere (e.g. a per-script way to load deps locally) or manually disable any gadgets using Library A while working on Tool A. So then I need to serve all of //them// locally too to make sure my changes to Library A don't break them. It would be much easier if I could temporarily redirect `ext.gadget.LibraryA` to the local script for dev purposes (which would apply to Gadget A and B too). So that any JS using that script will actually get the dev script, transparently. [If I have missed an existing best practice for development here, I apologise, but I couldn't find one in the existing documentation.]

I have some scripts, some of which are Gadgets, that depend on "library" scripts. For example, say I have user-script "Tool A" and gadgets "Gadget A" and Gadget B" that all depend on "Library A", which hangs its API from `window.LibraryA`. Library A is a Gadget too, so I can load it with `mw.loader.using("ext.gadget.LibraryA")` from Tool A, while Gadgets A and B declare it as a dependency in `gadgets-definition`. However, when I am developing Tool A, I may want to also adjust Library A. Normally, I serve the JS locally for development, so I use something like `mw.loader.load("https://localhost/libraryA.js")`. This means that if I have Gadgets A and B enabled, I'll be loading two copies of Library A, one from the wiki and one locally, which will compete for the `window` slot. So I have to hack in guards somewhere (e.g. a per-script way to load deps locally) or manually disable any gadgets using Library A while working on Tool A. So then I need to serve all of //them// locally too to make sure my changes to Library A don't break them. It would be much easier if I could temporarily redirect `ext.gadget.LibraryA` to the local script for dev purposes (which would apply to Gadget A and B too). So that any JS using that script will actually get the dev script, transparently. [If I have missed an existing best practice for development here, I apologise, but I couldn't find one in the existing documentation.]

I have some scripts, some of which are Gadgets, that depend on "library" scripts. For example, say I have user-script "Tool A" and gadgets "Gadget A" and Gadget B" that all depend on "Library A", which hangs its API from `window.LibraryA`. Library A is a Gadget too, so I can load it with `mw.loader.using("ext.gadget.LibraryA")` from Tool A, while Gadgets A and B declare it as a dependency in `gadgets-definition`. However, when I am developing Tool A, I may want to also adjust Library A. Normally, I serve the JS locally for development, so I use something like `mw.loader.load("https://localhost/libraryA.js")`. This means that if I have Gadgets A and B enabled, I'll be loading two copies of Library A, one from the wiki and one locally, which will compete for the `window` slot. So I have to hack in guards somewhere (e.g. a per-script way to load deps locally) or manually disable any gadgets using Library A while working on Tool A. So then I need to serve all of //them// locally too to make sure my changes to Library A don't break them. It would be much easier if I could temporarily redirect `ext.gadget.LibraryA` to the local script for dev purposes (which would apply to Gadget A and B too). So that any JS using that script will actually get the dev script, transparently. [If I have missed an existing best practice for development here, I apologise, but I couldn't find one in the existing documentation.]