Open aclist opened 1 week ago
Note: access to local file URIs is only available on Chromium for Tampermonkey. Therefore, using a remote resource continues to be a better workaround, short of loading a local server and pointing to those URIs.
I now have a much easier method. The old gist generator script will be scrapped and replaced with a method that will serve all local files seamlessly.
@Pamasich I've pushed a new build script called local.sh
that can be invoked as usual from the root directory as ./build/scripts/local.sh
. It uses a basic functionality provided in Python 3 to open a local server listening on 127.0.0.1:8080 serving files from the /helpers
directory.
Prior to that , it should attempt to build the files below, inclusive of local changes:
It will then make a copy of kes.user.js
, named kes.user.js.alt
, and change the resource paths in that file to point to the those on the local server.
Then the local server will start listening, and you can copy the entire contents of kes.user.js.alt
and paste them into *monkey. When finished, the server can be terminated directly via the terminal.
Here is the relevant change:
1,3c1,3
< // @require https://raw.githubusercontent.com/aclist/kbin-kes/testing/helpers/safegm.user.js
< // @require https://raw.githubusercontent.com/aclist/kbin-kes/testing/helpers/kbin-mod-options.js
< // @require https://raw.githubusercontent.com/aclist/kbin-kes/testing/helpers/funcs.js
---
> // @require http://127.0.0.1:8080/helpers/safegm.user.js
> // @require http://127.0.0.1:8080/helpers/kbin-mod-options.js
> // @require http://127.0.0.1:8080/helpers/funcs.js
6,8c6,8
< // @resource kes_layout https://raw.githubusercontent.com/aclist/kbin-kes/testing/helpers/ui.json
< // @resource kes_json https://raw.githubusercontent.com/aclist/kbin-kes/testing/helpers/manifest.json
< // @resource kes_css https://raw.githubusercontent.com/aclist/kbin-kes/testing/helpers/kes.css
---
> // @resource kes_layout http://127.0.0.1:8080/helpers/ui.json
> // @resource kes_json http://127.0.0.1:8080/helpers/manifest.json
> // @resource kes_css http://127.0.0.1:8080/helpers/kes.css
This should obviate the need for fancy incantations when trying to prototype local changes and drop-in new mods that require manifest updates, etc. Essentially, everything you have locally is going to be reflected in KES after you paste the new file, so you can make local changes to other parts of KES as well in a non-destructive manner without needing to create lots of branches or host remote files or the like.
I'm mainly bringing this to your attention because I want to make sure the functionality is working on Windows correctly.
I'll test this out when I implement the changes to default_sort.
I'll most likely continue using my existing approach myself though.
Right, I think it becomes more of an issue when integration testing multiple third-party mods into the main KES and wanting to avoid creating too many remote branches for testing. However, this could prove useful for prototyping small interface changes locally as well.
Something seems to be wrong with the gist generator used to integration test mods by mocking KES resource files as remote gists, possibly related to fine-grained personal access token rotation.
Also, the script should create ephemeral copies of all relevant helper files associated with testing, not just the concatenated functions file: