Blake Embrey

If I'm reading this correct, all it'd be is exposing `paths` from `resolve`, right? That way it falls back to hard-coded paths to search on.

Internally we're requiring the different `detective` instances for you and assuming they follow the same API (currently file contents as first argument: https://github.com/dependency-check-team/dependency-check/blob/fc2d072c27b2d14614f74db658ab629e78ba2549/index.js#L326). I think the right thing to do...

I would go for the latter, an options object. It looks like a couple already have an options object (which makes it a backward compatible change), and it’s easier to...

That’s an interesting pattern. It wouldn’t work locally since node module resolution wouldn’t be able to find it, and given that it seems like it definitely should not be enabled...

`dependency-check` will need to adopt a plugin-like approach to make this work. Some way where we can add modules that list dependencies, and modules that parse out `require` calls.

@colthreepv Thanks, this is great! Would you like to contribute these instructions to the README? Edit: I can also deprecate this package with a link to the instructions once we...

Should be. Try `import * as React, { StatelessComponent } from React`.

You're right, sorry. I'm not sure then. I'd just use destructing like normal: ```js import * as React from 'react' const { StatelessComponent } = React ```

If you'd like, feel free to verify the behaviour is the same as with StandardJS. They're using it from https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-duplicates.md, so there may be a deviation in TSLint if your...

Both imports are identical in JS vs TS, there's no _real_ difference. If what you mean is about `StatelessComponent` as a type, you can import from a namespace but it...