briancavalier

// Use native or try any of these promise impls.
// They all behave the same.
//var Promise = require('when').Promise;
//var Promise = require('rsvp').Promise;
//var Promise = require('bluebird');

// Here are 2 promises, p1 and p2. p2 always *actually* finishes
// first, since p1 finishes in 1 millisecond, and p2 is already
// finished when created

briancavalier

module.exports = curry;

function curry (f) {
	var arity = f.length;
	var params = [];
	var end = createEnd(f, arity);
	return createCurried(params, arity, end);
}

function createEnd (f, arity) {

unscriptable

module.exports = curry;

function curry (f) {
	var arity = f.length;
	var params = [];
	var end = createEnd(f, arity);
	return createCurried(params, arity, end);
}

function createEnd (f, arity) {

wycats

// A. Create a new object that will contain the names ES6 module exports. We create it immediately so that
// it will work across cycles.
var es6Out = {};

// B. Assign it immediately to module.exports so other files that try to require this file will see it
// right away.
module.exports = {
  __es6_module__: es6Out
};

dherman

Notational Conventions

This section describes the conventions used here to describe type signatures.

A [T] is an array-like value (only ever used read-only in this API), i.e., one with an integer length and whose indexed properties from 0 to length - 1 are of type T.

A type T? should be read as T | undefined -- that is, an optional value that may be undefined.

Loaders

unscriptable

/**
 * This is a simple module with no id.  The loader will assign an id
 * according to the url where this file was found.  This is done with
 * a mapping of id:url, typically, but could be done via url:id as is 
 * proposed by some ES6 discussions.
 */
define(function (require) {
	var wire, spec;
	
	wire = require('wire');

domenic

This is in response to @BrendanEich's tweet:

that aside, mismatch, e.g., 'export = function...' and 'import f from M' should be an error -- right?

It needs more than 140 characters to reply. In short, the answer is no: this breaks abstraction boundaries. A module consumer should not know which style the module author is using. Indeed, this is a refactoring hazard, disallowing introduction of new behavior for the module being consumed (viz. [[Call]] behavior for export = function () { } or [[Construct]] behavior for export = class { }.)

How I Think It Should Work

Given these modules:

domenic

module.exports = and ES6 Module Interop in Node.js

The question: how can we use ES6 modules in Node.js, where modules-as-functions is very common? That is, given a future in which V8 supports ES6 modules:

• How can authors of function-modules convert to ES6 export syntax, without breaking consumers that do require("function-module")()?
• How can consumers of function-modules use ES6 import syntax, while not demanding that the module author rewrites his code to ES6 export?

@wycats showed me a solution. It involves hooking into the loader API to do some rewriting, and using a distinguished name for the single export.

This is me eating crow for lots of false statements I've made all over Twitter today. Here it goes.

unscriptable

define(function (require, exports) {
  var foo = require('foo');
  exports.bar = 'bar';
});

// this also works:
define(function (require) {
  var foo = require('foo');
  return { bar: 'bar' };
});

elijahmanor

Animated Gifs