-
-
Notifications
You must be signed in to change notification settings - Fork 405
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
Improve generator discovery #352
Comments
Meh. I'm against anything that directly boils down to popularity. A generator might be popular because it was made by an influential company, because it was promoted much, because the thing it scaffolds is something really popular (a popular framework for example), ... All of those don't say anything about the actual quality of the generator.
I like this idea a lot, though be aware that a list of "good" generators is super hard to maintain. We can't keep track of all generators that people develop. Also everybody will consider the generator they build good, and as a result we will have to discuss and deal with a bunch of PRs from people adding generators to the list. Besides from that, good generators might be outdated a year later, we'll have to follow all of them up. If we want to have a solution like that, we will at least need really strict and objective rules on what we consider "good". Also, ref yeoman/yeoman.io#459, as we'll need such a list of "top" generators too.
Lovely ideas, Sindre. What annoys me personally is that there are a bunch of really bad, duplicate, or simply nonsense generators out there. Maybe we should consider a blacklist, similar to what Gulp does for their plugins site. That would mean that Some people end up forking a generator to do a small opinionated change and publish that to npm. There's nothing wrong with that, it's even good, but it makes the list of choices often long and very noisy. |
@arthurvr FWIW, we have a blacklist currently. But as anything, you need someone to watch and maintain, and that's not the coolest task. That's why having a vetted list of high quality generators is probably a better option. |
@arthurvr If you see anything low-quality → https://github.com/yeoman/yeoman.io/blob/master/app/blacklist.json ;) |
I generally agree about GitHub stars. It's just the only automatic metric I can think of, even though it's flawed. We can leave that out though if we go with vetted generators. |
Hey, FWIW, the colors are not showing up right in iterm2. Because of this, the install list page is very hard to use in my case (it's all the same color). I believe we should validate the look on a couple terminal app, as if only OSx terminal display the colors correctly, I believe will do more harm the help. |
Probably more of a bug in the color scheme that you're using than a bug in our code. Some color schemes (like solarized) tend to hide away gray, for example. I don't think we'll find a catch-all solution that works fine with every color scheme. I'm using iTerm too and it works perfectly.
I knew about that one, but as long as we don't have objective rules when something is "good" or "bad" it doesn't make so much sense. Also, doesn't that list only apply to the site? I would think it does as it's in the yeoman.io repo...
Well, you have to maintain such a list of high quality generators too. I would think it even requires more maintenance. I honestly want both a list of super good things and(!) a blacklist. |
@SBoudrias I guess we can go with |
I like every idea that improves discoverability over what we have at the moment and what npm provides. I agree with @arthurvr that stars are a flawed metric for quality and manual curation can be difficult. That said, stars are certainly easier to integrate into that system and we could still see what it would look like in practice and decide from there if we'd like to keep it. |
@arthurvr The thing with shipping product is that we need to handle bugs in implementation. This is what we do everyday we work with browser. In this case our client is the terminal, so we need to handle and workaround issues that are going to affect our user. Solarize is a widely used terminal theme and if we don't fix this a lot of our user will be hitting that issue. About the stars, we currently use them on http://yeoman.io/generators to classify generators. I believe it does an okay job for an automated metric. |
No → Line 73 in 7efa7e0
|
Ah, alright. I should have done a quick search before :p |
Coming back to this almost a decade later: I think any usability improvement suggestion for the CLI is good and deserves its own issue. Otherwise per yeoman/yeoman#1779 we don't have maintenance budget to do long repeated tasks like updating an allowlist/denylist.
👍 from me. Converted to an issue: #851
👎 That Heroku app no longer exists 😄 so I think we can assume this refactor/rearchitecture suggestion has aged away. Edit: or, moved to #361. Either way!
👎 from me for the reasons stated in this thread. GitHub stars are relatively easy to game. npm search has its own relevancy metrics; I don't think there's a lot of value in trying to get a better system on the CLI. The CLI isn't even the primary search medium for most users. That's the website.
👍 from me, seems like a good small improvement & opportunity to share code. Converted to an issue: #852
Definitely out of scope now. If someone wants to file an issue and advocate for any of the features I 👎d, please go ahead! This is not a permanent "no", just an explanation for why I'm not moving them forward myself. Cheers! 🎩 |
The generator search in the yo CLI leaves a lot to be desired.
I just made it so that the generator description is shown in the search: f5ab6e9
This is how it currently looks:
But, I think we can do a lot better!
Some other things I think we should do:
Thoughts? Any other suggestions on how we can improve it?
I will open separate focused issues when we've decided on what to do.
The text was updated successfully, but these errors were encountered: