domenic

Comparing Different Implementations of process.nextTick using the Q test suite.

Used: q-spec.js@a1a416.

Implementations compared:

Based on MessageChannel

This is currently in Q:

unscriptable

// Typical AMD factory that returns a value, but uses an r-value (sync) require(),
// rather than a long, awkward dependency list.
// You cannot use module.exports or exports to declare the module:
(function (define){
define(function (require) {
"use strict";

	var mod = require('pkb/modA');

	return {

unscriptable

There are a couple of things that bug me about RequireJS's data-main method of single-script loading:

<script src="js/requirejs/require.js" data-main="app/main.js"></script>

1. the built file (bundle) must be named "require.js". WAT.
2. it just seems backwards.
3. data-main does not follow w3c recommendations since it's not name-spaced.

unscriptable

(function (define, frakkedConstructor) { define(function (require) { "use strict";
	var removeCommentsRx, findFuncRx, fracPrefixSrc, fracSuffixSrc,
		undef;

	removeCommentsRx = /\/\*[\s\S]*?\*\/|(?:[^\\])\/\/.*?[\n\r]/g;
	findFuncRx = /(function\s+NAME\s*\([^\{]+\{)|(?:[^\\]?)(["'])|(\{)|(\})/g;

	// TODO: allow individual parameters to be modified
	// TODO: allow function return to be modified or passed to after()
	fracPrefixSrc = 'frak$backs.before.apply(this, arguments); try {';

elijahmanor

Animated Gifs

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' };
});

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.

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:

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');

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