Skip to content

ES modules: "main" and "module" in "package.json" #199

Open
@cartant

Description

@cartant

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?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions