Support installing as Grunt/Gulp tasks.

[thinkingmedia]

It's possible to add Grunt tasks and Gulp tasks so that this tool can be used as part of a build script or testing.

[basicallydan]

@thinkingmedia Sorry this took so long to reply to. Massively not cool.

So - yes, that would be a good idea. We should do that. Do you know where to start with that/would you be interested in taking up the task?

[thinkingmedia]

@basicallydan yes, I can do a pull request for Grunt support.

I picture something like this running as a lint task. Have you ever used jslint?

https://github.com/douglascrockford/JSLint

[thinkingmedia]

@basicallydan

To run as a grunt task the forkability report needs to be generated using the current working directory. Is that possible? Looking at the index.js it appears setup to use the Github API only.

To be a grunt task it needs to generate the report on the folder before changes are pushed to Github.

Is this possible?

[M-Zuber]

Hmm. This is intriguing, but would probably require a decently heavy rewrite of internals- or adding a new api that works on local files.
Will add more feedback in the morning

[basicallydan]

I'm afraid that this wouldn't totally work. When using the directory we'd have to compromise on functionality. Forkability would still support:

• Linting of files
• Tags
• Issues
• The ignore file

But it wouldn't support:

• Issues
• Pull requests

I'm not saying that wouldn't be helpful, but it would mean essentially a "cut-down" configuration of Forkability.

And as @M-Zuber said, it would also mean a heavy re-write. I don't think it'd be very heavy though. Most of the re-writing would happen in lib/app.js since that's where the data retrieval step is. None of the lint*.js files make GitHub API requests. We'd merely need to get the structure of the specified directory and put it into a format which lintFiles.js understands.

I think if this is done we should create a generic API for data retrieval and the appropriate module can be selected. I'm sure there are good modules out there for understanding local git data, too.

I'm personally OK with this, but IMO organisation is really important, or we risk polluting app.js. And we need to make it really clear to users what they're compromising on. @M-Zuber thoughts?

[M-Zuber]

Great write up.
I was thinking of initially simply creating two modules: one that encapsulates the current functionality, and the other that works over a local directory.

Then the refactor can be very simple:

• Add a flag to lint a local directory
• If it was not sent, just lint using the github api.

As far as code reuse goes, that can even be done at a later date.
Such a structure may also enable us to support other sites in the future.

Did I answer all your points?

[basicallydan]

@M-Zuber Yep, sounds like we're on the same page.

So for the gulp/grunt tasks it'd use the flag.

We might need a few modules though. One for looking at files and one for getting the tags from the .git directory. Having said that, do you know @M-Zuber if it's possible that not all the tags will be brought over when cloning the repo?

[basicallydan]

Also, if we're gonna do this let's make two more issues: One for creating a local directory structure retriever which has a function to produce the data in the appropriate format, and one for a module to retrieve tags.

@M-Zuber We agreed this is a good idea?!

[M-Zuber]

Great idea!
re tags not being brought over, I have no idea but will tweet some people

[thinkingmedia]

I think this just grew in complexity beyond what I can do at this stage, but having written many grunt tasks. I'd be happy to help add the grunt support when you're ready.

[basicallydan]

@thinkingmedia Cool - that's totally reasonable, thank you.