Would be even more awesome with system requirements by package

[jtrussell]

For example, a number of these (hypercwd and hyper-statusline to name a couple) don't work on Windows and their authors have no plans to add support. This makes for a pretty not-awesome experience for the plucky Windows user going down this list installing plugins :(.

[chabou]

Yes we need to improve that.
It might be awesome if we can filter plugins based on this OS compat. But seems impossible with a .md based list.

It could be a lot of work to test existing plugins. How can we handle this? We can contact plugins author, but we should offer a way to make easy for the Community to help.

[jtrussell]

I wouldn't mind contributing along these lines if there was an obvious way to mark comparability requirements. Low tech is fine, even just a note on the row or additional column with OS icons would work.

Ideally the package authors would note OS requirements in their own package.json... Maybe compat PRs to this list should point back to either an OS declaration in the plugin's package.json or a PR for the same?

[chabou]

What do you think about this?

[bnb]

Love this idea, and it looks like that's a damn solid implementation. I have two concerns, neither of which are hard blockers, but something we should consider:

1. How do we test and maintain this long term? What if a module adds support for stops supporting one platform? Not a blocker, but would probably want to add some documentation around this.

2. Adding indicators means extension authors may need to know if their tools work on each platform. I don't know if we want to raise the barrier-to-entry of adding to the list by requiring people to test/declare support for each of these platforms. Again, not a blocker but something to consider before implementation.

[chabou]

1. Most of plugins are fully compatible. Only some plugins have some OS limitation due to libs used. I think that plugin could only have better compatibility with time. It could have a temporary bug on a specific OS or a disabled feature, but most of time, compatibility will not be reduced but improved. In this case, I think that plugin author will be proud to update it in awesome-hyper

2. We can maybe change indicators to have 3 types for each OS: Compatible, not-compatible, untested (like non-compatible but with a interrogation point over it). If we want to do this, we need a way to have a community-driven indicator rather than plugin authors, but it will be complicated with a MarkDown. But I really think that plugin author can guess if his plugin works on different OS and accept issues on this OS. I think it will not be a barrier-to-entry for high quality plugins ;)

The best example is the last approved plugin which has a disclaimer about working only on MacOS directly in its README.

But you're right, it is a change with potential big impacts that need to be carefully weighed.

[jtrussell]

That looks very nice!

Some thoughts:

Plugins can declare OS dependencies in their package.json, e.g. I submitted this PR to hyper-statusline a little while back. It's likely not very well maintained but could be useful for auto-generating the initial info. Could also help in future to flag package changes for compatibility review. I'd suggest PR's here could point back to either issues or PR's noting/fixing/reporting compat issues for the package in question.

You could take a hard line and completely derive your compat data from that field and then just redirect folks to hound package authors to correctly declare their OS compatibility.

Aside from something along those lines I feel like relying on the community to keep the list up to date is your best bet.

[chabou]

You are right, we should use (and encourage) OS compatibility declaration in their package.json.
But it is better to not require it to reduce barrier-to-entry.

With my OS proposal, writing a row is hard with all these elements : name, description, OS badges and download badge. To make PR easier, I made a little tool to automatically format this row: https://awesome-hyper-linkmaker.now.sh

It takes description AND os-compatibility from NPMJS (so, from package.json), but user can modify them before copy/paste row.

We can maybe add a warning when user modify os-compatibility to encourage him to add/update it to its package.json.

I have no idea how to have feedbacks from community to keep this list up-to-date without a real website. Issues can be opened but it doesn't seems user-friendly.

[bnb]

I think GitHub issues would be a 👌 way to get feedback - if you try to download/use a module and it's not supported on the platform that awesome-hyper says it is, create an issue and we'll update our README. Could also go and create an issue on that plugin/theme's repository and link back to the awesome-hyper issue to let the maintainers know 😅

I think the way to implement this would be to simply put a boilerplate paragraph in front of each section that states supported OS is community-maintained, and if you find that it's not accurate you can open an issue and we'll update.