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

2016 Roadmap #1571

Open
addyosmani opened this Issue Nov 28, 2015 · 27 comments

Comments

Projects
None yet
@addyosmani
Member

addyosmani commented Nov 28, 2015

Some ideas mixed with issues we're already tracking. Expanding from our conversations on team hangouts:

  • All official generators support npm3 for front-end packages (#1521)
  • Get consistent with linter (ESLint) and ES2015 transpiler (Babel) support across our generators
  • Audit: trimming down size of our dependency trees / install times (independent of npm3 slowness)
  • Improve search/discovery. Both in the site and CLI. Make it easier to locate a generator for a specific framework or problem. Perhaps we do this through visual grouping based on keywords (e.g here are the React generators) or something like npm's collections/ecosystems. Consider hiding generators not updated in N years?
  • Rewrite official generators to use gulp 4 (once it ships).
  • HTTP/2: Research if our perf optimisation recommendations require rethinking/guides for HTTP/2
  • Validate project dependencies licenses more tightly (#1523)
  • Research/discuss if there's value switching to a tasks directory for all Gulp generators to enable easier drag/drop reuse of tasks.
  • Speak to framework authors more to understand their needs better. Are the fw-specific CLI tools we're starting to see something yo can better evolve to serve?
  • 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)
  • Decide on whether official generators continue to support Grunt or we drop it in support of Gulp across the board.
  • Site: refresh to position yo as a more general scaffolding tool (yeoman.io#568)
  • Site: dedicated page to highlight third party editors that support us. WebStorm, MS Visual Code etc.
  • Site: deprecate the Angular 1 Yeoman CodeLab. Let's come up with a new one focused around 1 x official generator that's generic (generator-gulp-webapp?) and encourage 2 x other popular generators to write codelabs we can refer to. Ideally, I'd love something around React/Polymer/ng2
  • Discuss how we can help enable more Progressive Web Apps to be built
  • Find a dedicated Google Developer Expert or Community manager for the Yeoman project. We really, really need this to get the word out about great work the team is doing.

Feel free to add more ideas plz <3z

@hemanth

This comment has been minimized.

Show comment
Hide comment
@hemanth

hemanth Nov 28, 2015

Member

Adding on the Improve search/discovery, section:

Member

hemanth commented Nov 28, 2015

Adding on the Improve search/discovery, section:

@ruyadorno

This comment has been minimized.

Show comment
Hide comment
@ruyadorno

ruyadorno Nov 29, 2015

Member

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

Member

ruyadorno commented Nov 29, 2015

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

@dylang

This comment has been minimized.

Show comment
Hide comment
@dylang

dylang Dec 28, 2015

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 commented Dec 28, 2015

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.
@dancancro

This comment has been minimized.

Show comment
Hide comment
@dancancro

dancancro Dec 28, 2015

@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.

dancancro commented Dec 28, 2015

@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.

@sindresorhus

This comment has been minimized.

Show comment
Hide comment
@sindresorhus

sindresorhus Dec 30, 2015

Member

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

Member

sindresorhus commented Dec 30, 2015

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

@sindresorhus

This comment has been minimized.

Show comment
Hide comment
@sindresorhus

sindresorhus Dec 30, 2015

Member

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...

Member

sindresorhus commented Dec 30, 2015

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...

@sindresorhus

This comment has been minimized.

Show comment
Hide comment
@sindresorhus

sindresorhus Dec 30, 2015

Member

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

Member

sindresorhus commented Dec 30, 2015

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

@dylang

This comment has been minimized.

Show comment
Hide comment
@dylang

dylang Dec 30, 2015

@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 commented Dec 30, 2015

@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!

@SBoudrias

This comment has been minimized.

Show comment
Hide comment
@SBoudrias

SBoudrias Dec 30, 2015

Member

@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.

Member

SBoudrias commented Dec 30, 2015

@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.

@ragingwind

This comment has been minimized.

Show comment
Hide comment
@ragingwind

ragingwind Dec 30, 2015

Contributor

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

Contributor

ragingwind commented Dec 30, 2015

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

@ejohnsonw

This comment has been minimized.

Show comment
Hide comment
@ejohnsonw

ejohnsonw Dec 30, 2015

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.

ejohnsonw commented Dec 30, 2015

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.

@addyosmani

This comment has been minimized.

Show comment
Hide comment
@addyosmani

addyosmani Feb 21, 2016

Member

@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.

Member

addyosmani commented Feb 21, 2016

@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.

@gruppjo

This comment has been minimized.

Show comment
Hide comment
@gruppjo

gruppjo Mar 15, 2016

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.

gruppjo commented Mar 15, 2016

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.

@kkemple

This comment has been minimized.

Show comment
Hide comment
@kkemple

kkemple Apr 18, 2016

@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 commented Apr 18, 2016

@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!

@SBoudrias

This comment has been minimized.

Show comment
Hide comment
@SBoudrias

SBoudrias Apr 18, 2016

Member

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

Member

SBoudrias commented Apr 18, 2016

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

@kkemple

This comment has been minimized.

Show comment
Hide comment
@kkemple

kkemple Apr 18, 2016

@SBoudrias thanks for pointing me in the right direction!

kkemple commented Apr 18, 2016

@SBoudrias thanks for pointing me in the right direction!

@addyosmani addyosmani changed the title from Themes for 2016 to 2016 Roadmap Aug 30, 2016

@awayken

This comment has been minimized.

Show comment
Hide comment
@awayken

awayken Aug 8, 2017

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?

awayken commented Aug 8, 2017

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?

@mischah

This comment has been minimized.

Show comment
Hide comment
@mischah

mischah Aug 8, 2017

Member

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

Member

mischah commented Aug 8, 2017

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

@mischah

This comment has been minimized.

Show comment
Hide comment
@mischah

mischah Aug 8, 2017

Member

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

Do you have any special concerns?

Member

mischah commented Aug 8, 2017

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

Do you have any special concerns?

@SBoudrias

This comment has been minimized.

Show comment
Hide comment
@SBoudrias

SBoudrias Aug 8, 2017

Member

@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.

Member

SBoudrias commented Aug 8, 2017

@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.

@mischah

This comment has been minimized.

Show comment
Hide comment
@mischah

mischah Aug 8, 2017

Member

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

Member

mischah commented Aug 8, 2017

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

@awayken

This comment has been minimized.

Show comment
Hide comment
@awayken

awayken Aug 8, 2017

@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.

awayken commented Aug 8, 2017

@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.

@ImanMh

This comment has been minimized.

Show comment
Hide comment
@ImanMh

ImanMh Apr 16, 2018

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 commented Apr 16, 2018

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

@dvakatsiienko

This comment has been minimized.

Show comment
Hide comment
@dvakatsiienko

dvakatsiienko Sep 7, 2018

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

dvakatsiienko commented Sep 7, 2018

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

@mischah

This comment has been minimized.

Show comment
Hide comment
@mischah

mischah Sep 7, 2018

Member

@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.

Member

mischah commented Sep 7, 2018

@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.

@ImanMh

This comment has been minimized.

Show comment
Hide comment
@ImanMh

ImanMh Sep 7, 2018

@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.

ImanMh commented Sep 7, 2018

@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.

@SBoudrias

This comment has been minimized.

Show comment
Hide comment
@SBoudrias

SBoudrias Sep 8, 2018

Member

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.

Member

SBoudrias commented Sep 8, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment