feature request: about the author

[dylang]

On app stores when you find an app you like the stores also show you other apps by the same author. This is that concept but automatically generated for the readme.

I'm not sure how it would best work but here's my thinking:

• Either provide an npm user name or an array of npm modules.
• Choose how many to to display, defaults to newest 10.
• Optionally specify keywords such as gruntplugin.
• Use the npm registry api to get package information for each of them.

Example output:

Other Grunt tasks by Assemble

grunt-convert Grunt task to convert to or from JSON, YAML, XML, PLIST or CSV.

grunt-github-api Grunt plugin used to query the Github API and save the returned JSON files locally.

grunt-init-assemble Grunt init template for Assemble, the static site generator built on Grunt.js. Kickstart new Assemble projects in just a few seconds, including templates, data, layouts, and a theme.

grunt-firebase Grunt task for updating firebase data.

[dylang]

I might try building this myself as a separate node module. Can grunt-readme use async services to provide data for templates?

[doowb]

You should be able to build a module, then create a mixin and reference your module from there.

As for the async stuff, it doesn't look like anything is setup to specifically handle that. Do you have any suggestions on handling something like that?

[jonschlinkert]

I already have this working locally :-) It's funny how in sync we are on this

this use case was initially what really got me interested in https://github.com/assemble/grunt-github-api (I now see uses for it everywhere). So here is what I have working (locally):

I also created a plugin called "matchkeys" that is going to help with this. I'll try to push up today (cc @doowb since just had this conversation yesterday)

[jonschlinkert]

nvm on the cc'ing @doowb lol

[jonschlinkert]

I might try building this myself as a separate node module

Of course you could, no prob. It would be great to have you help get this integrated here though... since that was something we want to have as part of this plugin. (see: https://github.com/assemble/boilerplates/issues/10) which just captures part of the discussions we've had)

[dylang]

As for the async stuff, it doesn't look like anything is setup to specifically handle that. Do you have any suggestions on handling something like that?

Not sure. Would a callback or promise api for modules to use to populate the metadata be needed?

[dylang]

Oops wrong button.

[dylang]

I might try building this myself as a separate node module

Of course you could, no prob. It would be great to have you help get this integrated here though... since that was something we want to have as part of this plugin. (see: assemble/boilerplates#10) which just captures part of the discussions we've had)

Funny, we're thinking the same thing.

I was thinking it could be a separate module so that grunt-readme doesn't get too complex, and it could be required by grunt-readme and any other module that wants to use the feature.

[jonschlinkert]

Would a callback or promise api for modules to use to populate the metadata be needed?

Since this is part of the reason I really liked grunt-github-api, perhaps @JeffHerb could offer an opinion there too.

I was thinking it could be a separate module

That makes sense. Since we have such a need for it and have wanted to do this for a while would you be willing/interested in doing it as a maintainer for assemble? No worries either way

[jonschlinkert]

this has been implemented. See https://github.com/assemble/assemble-contrib-markdown#related-projects.

I decided to do this by creating a very simple dedicated task, repos: https://github.com/assemble/assemble-contrib-markdown/blob/master/Gruntfile.js#L26-L45

The task first pulls down a list of repos from the given user or org, and then the grunt-readme task just reads in returned json to extend the metadata object used to supply data to templates. It has worked out really well.

Example: https://github.com/assemble/assemble-contrib-markdown/tree/master/docs

Currently, I'm filtering the returned list of repos in the lodash templates, e.g.:

{% _.each(repos, function(plugin) { %}{% if(/\bcontrib\b/g.test(plugin.name) && plugin.name.indexOf(shortname) === -1) { %}

### [{%= plugin.name %}]({%= plugin.url %}) [![NPM version](https://badge.fury.io/js/{%= plugin.name %}.png)](http://badge.fury.io/js/{%= plugin.name %})
> {%= plugin.description %} {% } %} {% }); %}

But I plan to update the repos task to include some kind of filtering/whitelist/blacklist logic so that the templates don't need to be modified as much.

Closing this since the feature has been implemented, but please reopen if you think it's not resolved