excellent idea. few things feel like they need to be extensions, and this would also make it easy to hack on stuff like the zotero connector and maintain control over random tiny unmaintained extensions.
first things that come to mind: can every extension be converted? what do i lose in terms of usability, if anything? in a simpler time, i would have expected these things to be at the top of the docs if there were docs, or else for the docs to just be a nearly empty readme containing just "# TODO\nwrite readme"
repeat after me: if your readme wasn't worth writing, it isn't worth reading
the readme is the public face of the software that you are posting to this site for the consideration of potential users. why start by disrespecting them with a list of "Key Features" (linking to an equally doubtful-looking architecture document) that's just raw data that you didn't see fit to arrange into an introduction based on your understanding of what a human user might want?
even assuming it's all correct, which it might be if you've proofread it, nowhere in this impersonal wall of token vomit is there consideration for an actual user, because the purpose of these tools is management-brained report generation—and that is not what documentation is
You do have a lot of fair points I've been working on the README recently and will work on it a bit more soon, most of my work has gone into the actual code. Currently it's intended for extensions that:
1. Apply to only a few specific sites
2. Their functionality isn't entirely browser API based (this wouldn't make sense even if they're polyfilled)
3. "Could be" userscripts: It's an abstraction layer to make things work, not something to build on top of.
That aside it's pretty powerful and does a really good job on most extensions that meet this criteria. I'll let you know once I'm finished with the README, I'd love to have some feedback on it. It's worth noting there's a draft (totally human written) blog article in docs/article.md
Is there any tool I can use to sync the userscripts easily? last time I checked it requires some clicks and browse files. I want them to be included in my dotfiles and automatically synced on git pull
How about [TamperDav](https://github.com/Tampermonkey/tamperdav) - It's also worth noting that Tampermonkey supports syncing to Google Drive and Dropbox (though you don't get the same sort of version control) - I use dropbox syncing, then host my userscripts on github gist then install from there, that way they auto update from gist.
excellent idea. few things feel like they need to be extensions, and this would also make it easy to hack on stuff like the zotero connector and maintain control over random tiny unmaintained extensions.
first things that come to mind: can every extension be converted? what do i lose in terms of usability, if anything? in a simpler time, i would have expected these things to be at the top of the docs if there were docs, or else for the docs to just be a nearly empty readme containing just "# TODO\nwrite readme"
repeat after me: if your readme wasn't worth writing, it isn't worth reading
the readme is the public face of the software that you are posting to this site for the consideration of potential users. why start by disrespecting them with a list of "Key Features" (linking to an equally doubtful-looking architecture document) that's just raw data that you didn't see fit to arrange into an introduction based on your understanding of what a human user might want?
even assuming it's all correct, which it might be if you've proofread it, nowhere in this impersonal wall of token vomit is there consideration for an actual user, because the purpose of these tools is management-brained report generation—and that is not what documentation is
You do have a lot of fair points I've been working on the README recently and will work on it a bit more soon, most of my work has gone into the actual code. Currently it's intended for extensions that:
1. Apply to only a few specific sites 2. Their functionality isn't entirely browser API based (this wouldn't make sense even if they're polyfilled) 3. "Could be" userscripts: It's an abstraction layer to make things work, not something to build on top of.
That aside it's pretty powerful and does a really good job on most extensions that meet this criteria. I'll let you know once I'm finished with the README, I'd love to have some feedback on it. It's worth noting there's a draft (totally human written) blog article in docs/article.md
I have updated the README, also check out the article (WIP): https://github.com/Explosion-Scratch/to-userscript/blob/main...
Is there any tool I can use to sync the userscripts easily? last time I checked it requires some clicks and browse files. I want them to be included in my dotfiles and automatically synced on git pull
How about [TamperDav](https://github.com/Tampermonkey/tamperdav) - It's also worth noting that Tampermonkey supports syncing to Google Drive and Dropbox (though you don't get the same sort of version control) - I use dropbox syncing, then host my userscripts on github gist then install from there, that way they auto update from gist.