Description
I recently stumbled across this when importing an internal helper function from AngularFire2. What I found is documented here. (Hopefully, for the benefit of others.)
The latest Angular and AngularFire2 releases use the package.json
file's main
to refer to a UMD bundle and its module
to refer to an ES module (with ES2015 content). It's mentioned in this comment.
So an import
like this:
import { AngularFire } from "angularfire2";
will result in the UMD bundle will being added to the Browserify bundle, but an import like this:
import { unwrapMapFn } from "angularfire2/utils";
will result in an ES module being added, with the following error being effected:
ParseError: 'import' and 'export' may appear only with 'sourceType: module'
Typically, this won't be a problem - as it only occurs when using deep-path imports. However, if RxJS goes this route and uses main
and module
in its package.json
, it will be more distruptive, as it's pretty common to have imports like this:
import "rxjs/add/observable/empty";
import "rxjs/add/observable/of";
import "rxjs/add/operator/delay";
import "rxjs/add/operator/map";
import "rxjs/add/operator/switchMap";
The use of module
appears to be the "In Defense of .js" option that's mentioned in this blog post.
Some questions:
- Is there yet any concensus over how ES modules should be handled in
package.json
files? - How is TypeScript going to handle this?
- What are the chances of this being supported in Browserify before there is support in Node.js?