Use generator.name if set in yoyo

[sindresorhus]

Just uppercasing the first character doesn't look that good in some cases. Like with the H5BP generator.

Generators supports a name property: https://github.com/h5bp/generator-h5bp/blob/master/app/index.js#L39

Use that in yoyo if it exists.

Before: Run the H5bp generator After: Run the HTML5 Boilerplate generator

Maybe we should enforce generators to set a humanized name?

@stephenplusplus @passy

[stephenplusplus]

Currently, the H5bp comes from:

// namespace 'h5bp:app', comes from the env.lookup results 
prettyName = namespace.replace(':app', '');
prettyName = prettyName.charAt(0).toUpperCase() + prettyName.slice(1);

This is to avoid reading any files, causing a delay. Can you think of a way we can get a generator's chosen name in a non-speed affecting manner?

[passy]

I looked into it, too. I don't believe there is an easy way to realize this at the moment without massive performance drawbacks.

[sindresorhus]

We could make it so nothing is loaded when the generator entrypoint is required, but rather only when it's initiated with a function. That way we could read useful generator info, and only activate it when we need to. ?

An other alternative is to abuse package.json? { "yo": { "name": "HTML5 Boilerplate" }} But I don't particularly like that.

[addyosmani]

Agree. I dislike any abuse of package.json. Could we avoid that approach and experiment with Sindre's function initiation suggestion?

[passy]

How can we verify that nothing is loaded when the entry point is required? Or do you think of that as a convention?

[sindresorhus]

@passy convention.

[sindresorhus]

@SBoudrias any thoughts on this?

[SBoudrias]

That make perfect sense. I'd like Yeoman generators to export a main entry point with config and paths to sub generators.

The issue here would be to find a way that is backward compatible. And the answer is not that easy because a lot of generators currently set main to the *:app generator file.

Maybe we could create a config file. Let's say yeoman.js so we can require it require("generator-webapp/yeoman"). That way we'd avoid relying on the package main file.

[sindresorhus]

Maybe we could create a config file. Let's say yeoman.js so we can require it require("generator-webapp/yeoman"). That way we'd avoid relying on the package main file.

I rather we try to find a way to require main. That's the sane solution going forward. There might be something we can detect. At worst we could detect what generator version they're using before requiring.

[SBoudrias]

At worst we could detect what generator version they're using before requiring.

Yeah, I thought about that, but generators are consumed by yo who's version is controlled by the user, not the generator author...

But this might not be super important as it only mean new/updated generators wouldn't work with old versions of yo.

Still, I'm afraid using main might be error prone... Maybe a file named manifest.js or yo-manifest.js would make more sense? Using a manifest could even be a temporary solution for now, and eventually we move this file to simply being referenced by main.

[sindresorhus]

But this might not be super important as it only mean new/updated generators wouldn't work with old versions of yo.

Yeah, that's not a concern at all. It should be expected that people are running latest of yo. No reason not to.

Still, I'm afraid using main might be error prone... Maybe a file named manifest.js or yo-manifest.js would make more sense? Using a manifest could even be a temporary solution for now, and eventually we move this file to simply being referenced by main.

Error prone how?

I really prefer it if generators could be as close to an idiomatic node module as possible.

[SBoudrias]

Error prone in the way many generators references *:app in the main field. So, chances are some people gonna miss it and publish bugged versions on NPM.

That's why I feel using a manifest file first, then moving it to package.json main field, would be an easier transition.

I guess I could live with either solutions anyway.

[sindresorhus]

So, chances are some people gonna miss it and publish bugged versions on NPM.

Some people are going to miss something no matter what we do.

[fiznool]

Has there been any progress on this?

We have a generator for the Flow XO platform, called generator-flowxo, which is turned into Flowxo. Ideally we'd like this to read Flow XO.

[bradpearson]

This is, IMO, even a more needed feature as scoped packages are becoming more prevelant. We have several internal generators in the form @scope/generator-web-ui-app that display in the menu as @scope/Web Ui App.

[jcreamer898]

Similar problem here, we have @lonelyplanet/generator-travel-agent and it shows up like this...