Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bi-directional link to Github #288

Open
paponius opened this issue Dec 4, 2023 · 2 comments
Open

Bi-directional link to Github #288

paponius opened this issue Dec 4, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@paponius
Copy link

paponius commented Dec 4, 2023

Describe the change you'd like: We can link a style to Github, or other source, but when such the style is updated from Stylus plugin, it results in unexpected/undesired behavior. I guess this could also be defined as a bug.

Additional context: Would be nice if git sourced styles were linked to git, maybe using webhooks like on https://greasyfork.org/, and when a new one is uploaded, it's pushed to the git as a commit.

Otherwise, we can't use both git and upload button in Stylus.
And git is nice for bug report and collaboration features.

@paponius paponius added the enhancement New feature or request label Dec 4, 2023
@a0eoc
Copy link
Member

a0eoc commented Dec 4, 2023

We can link a style to Github, or other source, but when such the style is updated from Stylus plugin, it results in unexpected/undesired behavior

When source code mirroring is used, the style is replaced by the mirror version if versions don't match. It wasn't supposed to be used with manual code code updates out of sync with mirror updates.

Would be nice if git sourced styles were linked to git

I really like the idea of letting users set up such connectivity between software. It may not be reliable and it won't be easy to set up, but it will provide those who desire with the ability to do so. I think we can let users set up simple POSTs that will be sent on code updates, and that should be enough to update some file via GitHub API or on some other place. The only tricky part I see is what would happen if the target website (GitHub) was unavailable at the moment of POST. Retry logic sounds complicated.

Also, I think Stylus should have functional to publish styles to various places, not just USw. That would allow styles to be pushed to GitHub and then be pulled by USw, or allow to skip USw entirely if some Stylus users don't want to use it, while keeping Stylus as IDE.

Otherwise, we can't use both git and upload button in Stylus.

You can develop userstyles with any text editor as files on your disk, then drag the file in the browser's tab bar, which would trigger Stylus style installation, and then publish both new version from Stylus and push a git commit. But that would be a double work, which is why I personally just use git and not Stylus for development and publication. Maybe for now this workflow can work for you too.

There's also a nice "Mirror" button when mirroring is enabled, that allows to pull the new style version from the git instantly, but can only be used once in an hour.

@paponius
Copy link
Author

paponius commented Dec 5, 2023

Also, I think Stylus should have functional to publish styles to various places, not just USw.

Yes, this was my first thought exactly. But it seems the upload/publish feature is not considered a priority or necessity by Stylus devs:
openstyles/stylus#1242
openstyles/stylus#1031

So it seems we should be happy we have at least the option to upload to USw.
But, there is this issue, with the "unexpected/undesired behavior", when an update uploaded from Stylus to USw will show in USw and the user will go to sleep, just to wake up and find older version from git overwrote it later.

There are two options to fix this issue.
Bar updates for mirrored styles. So user will see an error in Stylus immediately.
Or let the user upload it and update the git from USw.
And I like the later more. So that's what I suggested.

workflow
see last 5 lines: https://github.com/paponius/userstyles#user-content-git
I think this is not just my problem, when I check an update history on non-working styles and see how sporadically they are updated. And on some, how long it takes to fix, when a site updates and breaks the style.
This was actually the main reason I started to write my own styles.
e.g. see dark stackoverflow style. Since September 2023 it was unreadable. It took over two months to fix it.
A standard/basic user would just switch away to worse style. Or uninstall Stylus all together, because they can't see text in sites.

As an author, if I can't fix an issue in one minute, I'll postpone it, possibly even forever.
And I can fix it in one minute using two-buttons-away Stylus IDE and one-button-upload.

I think the possibility to quickly fix a style is crucial for good quality of styles globally.
And that such techniques should be promoted.
Not implementing easier style fixing, because authors are not interested in it is a classic case of catch-22.

It wasn't supposed to be used with manual code code updates out of sync with mirror updates.
I got that. The reason I filled the Issue/enhancement is, that I think it's not optimally or correctly handled.

There is more to the issue of generic site publish.
With a possible upload to git feature, how to handle publishing of new styles. Where to put them. As a new repo? or in a dir? what filename?
How to get the pop-up you'll get when you Publish new style to USw now?

Next
Users prefer a Store, like USw, because git has a lot of buttons, no library view with styles from multiple authors, and it might look uncomprehensible to them overall.
But authors might like git more, for the versioning and Issue resolving features.
So some sort of tighter interconnection might be desirable. And it can't be made from the Github side.

That's why my suggestion for bast way forward was, to develop a full two-way mirror with git.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants