Been working on several scripts for a while and i must say i like it a lot, but found myself restricted by how they work
From what i understand you only have one file, and it must be readable ( i.e. not minified ). That makes it harder for me to develop a userscript using, say React for example.
Why would i need to use react, you say? Well that’s because i had an idea of a userscript that takes advantage of wanikani returning blank pages instead of a 404 page. In that i will use https://www.wanikani.com/my-script-name as a whole page for my script, and use react to render my application there
It’s a super cool idea in my opinion and i already made a script to test if it can be done… And it can! The build file for react has to be bundled in one file, Webpack solves that, but there’s no way the build file can be readable! Ugh!
So i guess my question is, can i ignore the “must be readable” condition? I can link the development source code in the build file if anyone wanted to read it or make changes
While I did have some success doing exactly that, there’s an issue where the script host (e.g. TamperMonkey) won’t always load your script. It’s a race condition at the load time of the 404/blank, so while it may seem to work reliably in your tests… it won’t work for everyone, and won’t be consistent depending on what other stuff is going on (like whether you have one script or many scripts in TamperMonkey). Several of us were able to confirm this.
As for React and other plugins – including minimized ones – you can link to them externally in your script header. See // @require.
The only requirement (for GreasyFork and openuserjs) is that external packages have to be hosted on an approved site. And that’s actually a good policy for security reasons: Greasy Fork's policy on external scripts
You don’t have to host on GreasyFork/Openuserjs, though. You could host on Github. But, personally, I wouldn’t use a script hosted on Github because the author can change the code at any time without notifying the user, and that opens the door to security issues. On GreasyFork, once you publish a version, you can never change it without TamperMonkey notifying the user that it’s a new version.
残念ですね〜
I can still go through my plans using AWS S3 as a host for my application, but I just wanted to avoid the cost of hosting and utilize userscripts. Guess Amazon is the winner here
S3 does not change the mutability factor that rfindley was addressing. Plus, the free tier of S3 gets you pretty far. Cdnjs is listed as an accepted provider and they do have react as well. It’s a non-issue then.
Can you elaborate on this? From what i understand, you’re saying i will still have issues with mutability even if it was hosted on S3? I don’t see why that could be
Well, if you host your files in a S3 bucket and you link to that, then (just like GitHub) what prevents you or anybody having write-access to just replace those files whenever?
Oh no don’t worry, i meant that i will serve my react application as a static website from an S3 Bucket, that means I’m crossing the idea of using a userscript in a 404 wanikani page entirely now and will host my application in a server instead of tembermonky
I’m giving up on the idea since i really can’t depend on tembermonky being consistent at all for this case