Expose module additionally to binary about jsinspect HOT 8 CLOSED

Would taking a look at https://github.com/eugene-bulkin/grunt-buddyjs/blob/master/tasks/buddyjs.js help? I think it should be a similar idea. Not sure I completely understand the question though. Wouldn't you be able to build the grunt task off of:

var chalk     = require('chalk');
var Inspector = require('jsinspect/lib/inspector');
var reporters = require('jsinspect/lib/reporters');

from jsinspect.

Well not really.

Let me explain - and maybe you won't agree. Which wouldn't be a problem. ;)

Currently there is a bit more logic inside of your binary, what makes it a bit harder, because if I would wrap it in a grunt task I've got two options.

Either I spawn a child process with the binary, which is (at least in my opinion) not so nice or I put also some logic inside of the grunt plugin, which makes it harder to maintain.

So what I'm thinking of is to make the binary as dump as possible and just call something like

var inspector = new Inspector( // some stuff here);

// all reporter logic and so on is inside of the module

inspector.run(function(err, results){
  // yeah we're done
});

inside. The binary would only deal with cli stuff like parsing arguments.

This would have a big advantage.

You'd be able to expose your module not only as CLI tool. Maybe some people want to use it just as a node module to build something with it and people that install it globally can still use it via the command line.

In my case wrapping it in a grunt task would only be

var inspector = require('jsinspect');
inspector.run();

No logic inside of the grunt task, because basically there shouldn't be any logic at all.

As an example maybe you want to check https://github.com/macbre/phantomas.

That's an awesome command line tool, but also gives the option to use it as a module only -> https://github.com/macbre/phantomas/wiki/npm-module.

Phantomas is also heavily event driven and deals also with tons of different reporters, but it keeps it all inside of one module, which makes it super easy to use later on.

It's basically just moving around of a bit logic and it would lead to a neat package ready to use without require more than the module itself. :)

So don't get me wrong, if you don't like it, that's totally fine. :)

from jsinspect.

Hm, I guess I'm confused by what logic you're talking about then. The only logic in bin/inspector is:

// Pass settings
inspector = new Inspector(paths, {
  threshold:   program.threshold,
  diff:        program.diff,
  identifiers: program.identifiers
});

// Retrieve the requested reporter, or use your own reporter if you want custom output
// This gives you some freedom since you just need something that listens to the right events
reporterType = reporters[program.reporter] || reporters.default;
new reporterType(inspector, program.diff);

// Run the inspector
inspector.run();

Everything else seems to be within the scope of what a binary should do? For example, retrieving the list of paths to files to run the inspector on, and the settings to use. The only difference that I see, from what you mentioned before, is that you have to instantiate the reporter yourself? But from a modular standpoint, that only makes sense - I'm allowing people to easily run the tool as a library, for which they can subscribe their own custom reporters. If I were to bundle both reporters/inspector together, it's no longer decoupled. Does that make sense?

Looking at phantomas as an example, it seems to have some logic shipped with the binary, rather than the actual library. https://github.com/macbre/phantomas/blob/devel/bin/phantomas.js#L163-L176 E.g. A grunt task would explicitly need to accommodate the potential broken results.

I might have misunderstood still though!

from jsinspect.

Hah, nice discussion - thanks for taking the time. 👍

• and hopefully I'm not bothering you. ;)

Okay - about the reporters makes kind of sense.

But then there is also another thing. The binary is reading files from the disk.

https://github.com/danielstjules/jsinspect/blob/master/bin/jsinspect#L38-L46

Which would mean, that the grunt task would have to read files from the disk also and then we have already a duplication, which may not be needed.

And about phantomas - that's a good one. 😆
I'm maintaining the grunt-phantomas task, and never had any problems. Have to dig, why this is inside of the binary. ;) Thanks for pointing that out.

from jsinspect.

But then there is also another thing. The binary is reading files from the disk. (...) Which would mean, that the grunt task would have to read files from the disk also and then we have already a duplication, which may not be needed.

It's not reading files from disk though, it's just getting a list of them. :) I wrote this absolutely terrible little module that just iterates over directories to build up a list of file paths: https://github.com/danielstjules/node-filepaths/blob/master/index.js It's not actually reading anything though - it's simply traversing directories when given a list of paths. Sorry, it doesn't have any documentation, and it's probably poorly written. I personally use it for jsinspect and buddy.js, but wouldn't expect anyone else to.

Edit: And I don't mind the discussion at all. 👍

from jsinspect.

hah, okay. :)

Yeah, I'll got the same approach as grunt-buddyjs then. Thanks for your patience.

from jsinspect.

Thanks for showing an interest in the project :)

from jsinspect.

Well I think it's great and it helps to keep code quality up. So I'll implement it my daily workflow as quickly as possible, when there is a grunt task available. ;)

from jsinspect.