Exported bindings? about rollup HOT 5 CLOSED

The code I passed to d3-bundler to test is:

import {event, select, selectAll} from "d3-selection";
export {event, select, selectAll};

The resulting output was:

(function (global, factory) {
    typeof exports === 'object' && typeof module !== 'undefined' ? factory(exports) :
    typeof define === 'function' && define.amd ? define(['exports'], factory) :
    factory((global.d3 = {}));
}(this, function (exports) { 'use strict';
    …
    var event = null;

    function listenerOf(listener, ancestors, args) {
      return function(event1) {
        var i = ancestors.length, event0 = event; // Events can be reentrant (e.g., focus).
        while (--i >= 0) args[i << 1] = ancestors[i].__data__;
        event = event1;
        try {
          listener.apply(ancestors[0], args);
        } finally {
          event = event0;
        }
      };
    }
    …
    exports.event = event;
    …
}));

from rollup.

Ah, yes - will need to implement this. IIRC Esperanto replaces all assignments to an exported value foo that take place a) after the export declaration or b) inside a function body with exports.foo = ....

I was wondering what would happen to d3.event. In d3-jsnext I had to cheat and use a global. Having it only be assigned to within selection-event will make life much easier, since it's illegal to assign to an imported binding.

from rollup.

FWIW, this is no longer blocking me because I’ve changed (yet again) the d3-bundler strategy to export a default object rather than use named exports. The new build looks like this:

import {
  event,
  select,
  selectAll
} from "d3-selection";

export default {
  get event() { return event; },
  select: select,
  selectAll: selectAll
};

And this works fine with Rollup just setting the local event directly.

from rollup.

I've changed some of the rewriting behaviour so that exported vars (or lets) are always rewritten as export.foo = .... Involves a little bit of dancing around, but I think it's the best solution. Hopefully I didn't introduce any bugs in the process.

Just so you're aware, using a default export will mean that Rollup wouldn't be able to (say) import select but not selectAll - it will always have to import the entire module. (Though it will look identical as far as UMD consumers are concerned.)

from rollup.

using a default export will mean that Rollup wouldn't be able to (say) import select but not selectAll

Right, but this module definition is the “end of the line” as far as composition goes: its only purpose is to generate UMD (or whatever), not to serve as another ES6 module to be imported elsewhere.

from rollup.