Adding on the Improve search/discovery, section:

• Tab completion (yo#222)
• Silent mode (yo#150)
• Easing installation (yo#149)

Decide on how to position the Electron yo-app work. If it's more than an experiment, we should mention it somewhere on the site (once it's ready for prime time)

👍 definitely want it to be more more than an experiment

I have had much less time available this year (since I decided to join the ranks with @stephenplusplus) so I'm making sure to focus the time dedicated to the project into getting it ready for prime time: adding tests, eslint, docs

One thing that can help yeoman-app a lot is to get more the word out, last time we advertised the project we even got a contributor to convert the entire react codebase to redux+es6

Hi, I'm not on the Yeoman project, these are just my own personal suggestions. I won't be offended if the teams thinks these are out of the scope for the project.

• Ability to use any git repo as a template. Ex: yo erikras/react-redux-universal-hot-example might copy the contents and ask for new name, and maybe do some other minor edits to the package.json. Obviously this is not as powerful as a true yo generator, but it expands the usage of the tool to include starter projects from authors who don't know about or care to create a generator.
• More predictable generator code layout. There's an app directory with USAGE and index.js, but because so much is unopinionated, it makes it difficult to compare generators. For example, finding the package.json to see what modules are used can be puzzling.
• Require package.json to be a valid json file. This is minor, but I frequently see _package.json made invalid JSON with template tags. This means tools like david and npm-check can't easily be used to check if Node modules are out-of-date. The _package.json could still be modified during runtime when producing the new package.json, like when users choose to include Sass, but this modification would be done programmatically with a new dependency API.
• If the above two happen, then we can enable searching for specific modules to be included. Ex: yo uses react webpack redux would list generators that use those modules.
• Make generators composable. I'm not sure how this would work, but the idea is developers might know what features or modules they want, but there's not going to be one generator that does it all. For example, I want to make a desktop app with data graphs, a testing framework, that uses the slack api, and code style checker. Checking those boxes somehow combines an electron generator, d3, mocha, slack, eslint, and things I might not realize I need to tie them together like webpack, which gets is automatically configured.

@dylang I'm not part of the Yeoman project either, but here's a couple comments on your comments.

There's this other related discussion going on among AngularJS folks making an Angular CLI who have chosen to adopt the ember-cli approach rather than Yeoman's on account of it supposedly supporting composition better. Sounds like what you're describing. Maybe you or someone reading this conversation would like to weigh in there.

Also, here is my offering to help make it easier to compare generators. I refer to them as 'starters' to include tutorials and examples among them. Besides starters, the database helps you compare frameworks, languages and tools on an extremely fine-grained level of detail.

@dylang We had to prefix package.json otherwise it's picked up by npm & causes an error on install 😕

Audit: trimming down size of our dependency trees / install times (independent of npm3 slowness)

I've done many rounds on this trying to get down the dependency size. The problem is that most module authors don't care at all and waste a lot of space by including all kinds of unrelated things like huge test fixtures, screenshots, etc, and are unwilling to change it...

@addyosmani Huge 👍 to all of this, but we'll need more people involved.

@dylang We had to prefix package.json otherwise it's picked up by npm & causes an error on install

@sindresorhus Prefix is fine, I can adjust npm-check to look for other filenames, but my hope is that the _package.json can be valid json and parsed like any other package.json file.

So none of this:

    "grunt-contrib-clean": "^0.6.0",<% if (coffee) { %>
    "grunt-contrib-coffee": "^0.12.0",<% } %><% if (compass) { %>
    "grunt-contrib-compass": "^1.0.0",<% } %>

I've adjusted my comment above to help make more more clear. Thanks for the feedback!

@dylang what we've been doing in recent generators update is to generate the package.json file totally in JS. - The thing is we need logic to decide which packages we include, no matter what.

You could add a unit test running npm-check after the project is generated to ensure the packages are up to date.

@addyosmani Great all of issues. Let's go move next.

I use yo for some of the generators available at www.generatron.com. The platform calls a generator and sometimes it gets stuck because there is a prompt. so 1+ for Silent mode or better yet a way of passing parameters.

@sindresorhus I think it's worth us sharing our goals for the year over on the project blog. Might also help get some fresh folks involved. I'll see if I can get something drafted up soon the rest of the team can take a look at.

Hi everybody, I really like where you're trying to go with yeoman.

I just commented (a really long one) on the angular-cli / generators discussion angular/angular-cli#49 (comment) since me and my colleagues experienced for the past 2.5 years what unfavourable outcomes the whole framework-cli approach can have at the example of the Ionic CLI. I also created an issue over at the Ionic CLI project to voice some concerns and suggestions ionic-team/ionic-cli#845.

I'm interested in getting involved.

@addyosmani i use yeoman just about all the time, even wrote about it here :: https://labs.mlssoccer.com/javascript-at-scale-achieving-high-velocity-160c7d78af03

I would love to get more involved in yeoman and if there is anything that I can do just let me know!

@kkemple help is always welcome on every aspect of Yeoman. We have a little getting started guide here http://yeoman.io/contributing/

@SBoudrias thanks for pointing me in the right direction!

I noticed that this roadmap hasn't changed very much recently. What is the future of Yeoman as far as the Yeoman community is concerned?

Thanks for the ping 🛎

You’re right. This needs to be closed and we need a new ticket for a »2017/2018 Roadmap«.
In this tickets are tasks which are done and obsolete. Others should make it to a 2017/2018 roadmap.

But just as @sindresorhus said above:

[…] we'll need more people involved.

cc/ @addyosmani @SBoudrias

What is the future of Yeoman as far as the Yeoman community is concerned?

Do you have any special concerns?

@awayken I think there's a few aspects to consider given Yeoman has a pretty large scope:

1. About the core (yeoman-generator, yo, yeoman-environment), I'd say these are pretty stable and haven't seen major upgrade recently (only maintenance/bug fixes releases). Sure we can always improve, but for most use case, this is good enough. Also, we're missing an active maintainer pushing new code and giving a new direction to the core system.
2. About the generators, these are now driven completely by the community. Apart from generator-node and generator-generator that the core Yeoman team still keep up to date, the other "official generators" have been either deprecated or deemed completed. I think the issue is that the scope was too big for the size of our team, so it's been hard to keep up with the many support requests. Community driven generators are better suited and usually have their own maintenance team (see for example generator-jhipster, generator-fountainjs and all the microsoft generators). I think this space is still very active and new generators are still published on a daily basis.
3. Somehow related to point 2, we've also seen quite a few <name your project>-cli (webpack-cli, react-native-cli) being powered by the Yeoman core system. So the core has also been used effectively behind the scenes by newer tools that more easily gather framework community. This is real work happening in the Yeoman community, but it is silent work; no one knows it's Yeoman.
4. About support, I think we're still very active answering to Github issues, Gitter and StackOverflow questions. When someone needs helps with Yeoman, they'll rarely have to wait more than a few hours before someone answer them. I think we're doing a great job on that front.

So is the project still active? Definitively. Are we working towards new releases? No, our focus is mostly towards support and maintenance (maybe someday someone will take over uplifting the core, but that's not the case right now). About "official generators", I've personally gave up maintaining them; and I think most of the other team members also have. Our broader community is 100% owning generator maintenance.

@SBoudrias Thanks for the write up. Very on point like always 💖

@mischah I built some generators at work a couple years ago (wow, has it been that long?) and am now coming back to the project that uses them. I've decided they can probably use some tweaking and modernizing, but I first wanted to check the pulse on Yeoman.

I'm a longtime fan and admirer of the project. However, I noticed two things that made me nervous: the blog was old, and this roadmap ticket seemed to have stalled. On the outside, it's hard to tell if that's the sign of a project that has naturally slowed from maturity or slowed from obsolescence and abandonment. I'm very happy to see it's the former.

Thanks to everyone for their quick responses.

It's 2018 and I'm still developing Yo generators with 2015 syntax. That would be grate if we could do something about it.

@ImanMh agree. Yeoman is a great tool, it is sad to see this happening extinction of this project

@ImanMh It's 2018 and I'm still developing Yo generators with 2015 syntax.

What do you mean by that? The syntax you use depends on the Node.js version(s) you’d like to target.

@mischah That's pretty obvious. Just try to import Yeoman from it's package instead of requiring it and it doesn't work easily. Also writing generators with new JS features such as async/await, spread operator and generators would be much more fun. I wish at leas yeoman was presented with ES6 syntax in documents and generator-generator had a babel transpiler to do that.

Also writing generators with new JS features such as async/await, spread operator and generators would be much more fun.

How is this not possible? Yeoman is just JavaScript, it's not married to any specific JS versions. As a matter of fact, it works great with async/await and our official documentation uses it: http://yeoman.io/authoring/user-interactions.html

Node.js 8 and 10 supports almost all the features you want from ES6. We didn't ship a babel build with generator-generator because it's unnecessary to support current Node versions.

I don't know where you've heard Yeoman doesn't work with es6 or modern syntax - this is simply not true.

@SBoudrias I haven't heard Yeoman doesn't work with es6 anywhere, I tried it many times and I couldn't get it working so I searched a lot and couldn't find a single example either. I know that luckily Node.js 8 and 10 added ES6 features but I'm afraid you are not getting my point and you are just trying to proof that I'm wrong without showing me an example. I'm a big fan of Yeoman and I'm not happy to see that I have to wait until Node.js releases some of the features that I like to use.
here is my suggestion:
Release next Yeoman with support for a .babelrc configuration file. Users can choose what features they need to use, and generators can get transpiled(if needed) before running, also let's write all docs and demos with ES6 to remind that Yeoman is still modern, update and growing fast.

So this project is dead, right?