Support for NPM modules used via CLI *and* JS API

[kevgo]

I am using a tool that provides both a CLI as well as a JS API for running Node code bases. It is called Exoservice. Here is how it is used:

• in production, you run exo-js on the command line in the current directory to boot up the app
• during testing, my tests require the exoservice module and create a new Exoservice instance to run the code base. This has the advantage that it is much faster since no new subshell and Node process has to be forked, and I have more control over the instance this way.

Repo to reproduce the issue: https://github.com/Originate/exosphere-tweets-service

All NPM modules that expose CLIs (Mocha, NPM, Cucumber, etc) do - or should - behave this way.

In this situation, dependency-lint thinks that exoservice should be a devDependency, because it is only required in dev code (my tests). It doesn't know that I am also using it on the command line in production.

The most ideal scenario would be to teach dependency-lint to also parse shell scripts in the code base, so that it knows what is really going on.

The second best solution would be a config option that allows me to overrule/ignore any dependency-lint warning if I have to. Having a little AI that tries to help me by reasoning about my code is nice, but there are a whole range of situations that are more complex than it can understand, so dependency-lint (or any other tool) should never have the last word in something. That should always be the human user.

[charlierudolph]

Although I have access to exosphere-tweets-service, I'd suggest not giving references to private repos in issues on public repos.

So is your ideal solution is what is discussed in #18? I don't want to actually parse shell scripts and was hoping a simple text search would do.

I do like the idea of your second best solution. Could add an ignoreErrors configuration object, replacing the current allowUnused, where the user can specify to ignore errors for certain modules.

ignoreErrors:
  missing: [] 
  shouldBeDependency: []
  shouldBeDevDependency: []
  unused: []

[kevgo]

Yeah, the ideal solution would include a simple parser that understands which CLI command are used in a Bash script. I don't have such a parser at hand right now, but they are possible. ShellCheck might have one. For our purposes a simple fulltext search might be good enough of a parser here.

No matter whether or not we do that, I think the ignoreErrors configuration entry is the right first step here. W need that anyways to have all bases covered.