7
votes
What features do you want to see in a userscript manager?
I'm currently developing a minimal userscript manager who's main goal is to be fully auditable by any user in only ten minutes or so - my prototype uses less than 300 lines of javascript, and I'm trying to keep it that way.
To get the codebase this small, however, I have to be very picky with what features I implement - most notably, the code editor has to be very barebones. Are there any features that I'd be shooting myself in the foot by not including?
For example:
- syntax highlighting
- cloud sync
- regex url matching
- fullscreen editor (currently, it's just a browser popup - the intention is that you write code elsewhere and paste it in)
Any feedback is greatly appreciated!
Oh, interesting - I don't think I want automatic updates enabled (I imagine that's a very easy vector for malware), but I think having a manual update option is smart.
The .user.js feature is handy, I'll definitely look into it.
I'm using the Firefox UserScript API to handle most of the grunt work, and luckily that already supports wildcard URL matching. It's really reduced the amount of code I had to write, but it's also a bit limiting.
Thanks so much for the thoughtful reply! I'll keep all of that in mind.
Which browsers are you planning on supporting? The most important feature for me would be whether it works with Pale Moon, a fork of Firefox that I prefer. But since that browser has a 0.02% usage share and doesn't use the same plugin format as modern Firefox, I'm used to not being supported.
Will you be implementing all of the GM_ functions from the Greasemonkey API?
So far I'm only supporting modern Firefox - it has a userscript API that helps keep the project tiny. I'm not thrilled about that, because it doesn't even seem like chrome or opera are supporting that part of the webextensions API. I suppose one benefit of the small codebase is that porting it probably wouldn't take too long.
I'm still mulling over how compatible my plugin will be with Greasemonkey et al - Obviously it would be nice to use the existing library of userscripts, but ensuring 100% compatibility would probably triple the project's size. I think I'll probably offer some middle ground - fragmentation is a pain.
Thanks for sharing your thoughts, though! Those are both important issues I hadn't considered much. I doubt the overlap between people who use chrome and people who want to read browser extension source code is pretty small, so I might want to lean in to the niche privacy aware/FOSS browser community here.
Interesting idea!
I use Tampermonkey and the features I find the most important are:
In my opinion syntax highlighting is not important if you don't plan to have a fullscreen editor.
Personally I'm not into the cloud sync either (I prefer local backups) but I think it could be important to plenty of people.
As a disclaimer, I'm mostly a end-user for userscripts, not a coder.
Thank you!
Bauke also seemed to like the idea of detecting script files, so it seems that's a common preference. I already have toggling each script implemented, as well - I think that's really important, too. Thanks for your opinions regarding cloud sync and syntax highlighting!
Regarding regex in URL matching - The way things are currently implemented, url matching works with wildcards, but not regex specifically - so, here are some valid identifiers for scripts:
https://*.google.com/images/*<all_urls>However, adding actual regex support would require a lot of extra code, so I was hoping people wouldn't mind losing it. Is the wildcard support enough for your use cases? If not, could you give me an example of what kinds of domains you'd use a regex for?
Curious, why is that? Is it not a simple matter of switching from a glob match to a regex match? JS has regex built in.
Good question! Unfortunately, it's not such an easy change. Firefox has this nonstandard (or at least it isn't implemented anywhere else) userscript API that webExtensions can use - By using it, I've managed to keep my code from actually touching pattern matching, creating
<script>tags, or injecting anything. That has the benefit of keeping things small and simple, but it also means I can't mess around with the guts. That API only supports wildcards, so I'd have to fully abandon it and write my own injector if I wanted regex support.I checked and for all my uses cases wildcards are enough, so I'd replace regex support in my initial list with wildcard support. :)
Good to know! I'll probably just stick with wildcards, then, as it'll keep me from having to write more boilerplate.