Add ExternalResolver to filter modules which should not be processed

[ericf]

This adds a new resolver class, ExternalResolver, which can be used to filter-out modules which should not be parsed/validated by the transpiler becuase they're external to the system. The -e CLI option tells the compiler to ignore external modules, instead of trying to find/parse/validate them.

// bar.js
import React from 'react';
export var bar = 'bar';

// foo.js
import {bar} from './bar';

When the -e option is passed, the compiler will see that the module 'react' is external and therefore ignore trying to find it, parse it, and validate it.

---

This relates to this discussion: #126 (comment)

[caridy]

LGTM, my only comment is about the feedback to developers, since "externals modules" are not allow by default, when an error occur, they might be clueless about how to solve this issue. But I think we can solve that with the proper notes in the docs referencing external modules.

[ericf]

@eventualbuddha Could you please comment on this, I'm curious to see why you closed. At the very least I was hoping this PR would spur a discussion around this problem of external modules outside those you're trying to transpile.

[eventualbuddha]

@ericf I think this was actually closed automatically by Github when I deleted the target branch. I think it's time to reopen this discussion as @stefanpenner and I now think this is the biggest problem with adoption.

[ericf]

@eventualbuddha Yeah, agreed. This particular thing was one aspect, which is to signal the transpiler that the module I'm importing is external to the current code I'm building, therefore don't try to verify dependencies; e.g., loading React in the browser.

@caridy released es6-module-transpiler-npm-resolver which has solved a part of this, but requires the npm package to include a jsnext:main entry in its package.json that points to the ES6 Module entry point of the package.

Taking this further, we need to be able to reference dependencies that are both external and not written as ES6 Modules.

[caridy]

reference dependencies that are both external and not written as ES6 Modules, that's the part that I don't like, but I knowledge the need for it. In fact, I have another resolver that does exactly that:

https://github.com/caridy/grunt-bundle-jsnext-lib/blob/master/lib/npm-resolver.js

This one does not rely on jsnext:main directive, and instead, it requires the module using require(), analyzes the exported members, and creates a synthetic ES6 shim to provide proper validation of the imports thru the transpiler. Maybe we should just abstract that resolver into its own pkg.

[eventualbuddha]

@caridy that sounds a bit like @stefanpenner's leaf project. Perhaps that could serve as a basis for your resolver?

[AdamFerguson]

👍 On this being an option to use as a resolver. The ExternalResolver is really helpful when you want to reference external libraries that are already compiled to AMD. Just helped me out on a project I'm working on.