nextTokenCanFollowDefaultKeyword doesn't really seem like an accurate name considering it's looking at multiple? Same with nextTokenCanFollowModifier. Would something like declarationCanFollowExportDefault be more appropriate?

I think the name is fine since it doesn't take a declaration as input, it just goes to the next token and looks at its kind and maybe does some minimal lookahead.

This is big enough now to deserve a switch statement.

Also test export default declare namespace

Also we should probably allow the old module keyword here as equivalent with namespace for consistency.

What about export default declare abstract class ?

I think that should be supported too.

This looks like an emitter bug -- It should be writing to exports.default.

Same emitter bug here -- should write to exports.default, not exports.N.

exports.N is a bit awkward here, but AFAIK should always be undefined, as things like the following aren't allowed?

export default class N {}
export class N {}

As I mentioned above regarding enum, in this case N should only ever be a local binding inside the module. This should read:

var N = N || {};
exports["default"] = N;
(function (N) {
    function foo() {
        return 0xC0FFEE;
    }
    N.foo = foo;
})(N);

We also should consider allowing a "nameless" namespace:

// ts
export default namespace {
    export function foo() {
        return 0xC0FFEE;
    }
}

// js
var _a = {};
exports["default"] = _a;
(function (_a) {
    function foo() {
        return 0xC0FFEE;
    }
    _a.foo = foo;
})(_a);

// alternatively

exports["default"] = (function () {
    var _a = {};
    function foo() {
        return 0xC0FFEE;
    }
    _a.foo = foo;
    return _a;
})();

Thanks for the feedback, I'll get started on it. Would a nameless namespace be equivalent to a "namespace expression"? In any case I see some issues when module=es6:

export default namespace {
    export const a = 2;
}
// namespace merge
export default namespace {
    export const b = 2;
}

// requires generated variable name:
var _gen0 = {}
export default _gen0;
(function (_gen0) {
    _gen0.a = 2;
})(_gen0);
(function (_gen0) {
    _gen0.b = 2;
})(_gen0);

As anonymous interfaces aren't allowed either currently, maybe this would be better handled as a separate issue?

That's a fair point, and perhaps we should hold off on nameless enum/namespace for now until the team has had an opportunity to discuss. My intuition is that you would not be able to merge with a nameless default namespace.

@DanielRosenwasser, @mhegazy: any thoughts?

lookahead is not free, so I would recommend combining the two operations into a single lookahead. Also, you really want to do 2 token lookahead here for abstract:

• default declare class - OK
• default declare abstract - Not OK (especially if its followed by function, etc.)
• default declare abstract class - OK

What about these:

• default declare function
• default declare async function (this syntax is invalid, however we report a more detailed error during grammar check)
• default declare namespace
• default declare module
• default declare enum
• default declare const enum

ClassDeclaration and FunctionDeclaration exported as default can elide the declaration name. Are we intending to support that for InterfaceDeclaration, EnumDeclaration, and ModuleDeclaration as well?

Avoid commented code.

If we intend for enum to work similar to class and function, then this is not the correct emit. Here you are exporting A as both A and default, where for a class or function it only exports default while the declaration name is a local binding only within the module.

With your new proposed emit this should instead be:

var A = A || {};
exports["default"] = A;
(function (A) {
    A[A["FOO"] = 0] = "FOO";
})(A);

If we plan to allow elision of the enum name (like you can with ES6 classes and functions), then you might emit:

// ts
export default enum {
  FOO = 1;
}

// js
var _a = {};
exports["default"] = _a;
(function (_a) {
    _a[_a["FOO"] = 0] = "FOO";
})(_a);

// or, alternatively:
exports["default"] = (function () {
  var _a = {};
  _a[_a["FOO"] = 0] = "FOO";
  return _a;
})();

As I mentioned above regarding enum, in this case N should only ever be a local binding inside the module. This should read:

var N = N || {};
exports["default"] = N;
(function (N) {
    function foo() {
        return 0xC0FFEE;
    }
    N.foo = foo;
})(N);

We also should consider allowing a "nameless" namespace:

// ts
export default namespace {
    export function foo() {
        return 0xC0FFEE;
    }
}

// js
var _a = {};
exports["default"] = _a;
(function (_a) {
    function foo() {
        return 0xC0FFEE;
    }
    _a.foo = foo;
})(_a);

// alternatively

exports["default"] = (function () {
    var _a = {};
    function foo() {
        return 0xC0FFEE;
    }
    _a.foo = foo;
    return _a;
})();

@rbuckton This simplified lookahead seems to be enough; see 5113249#diff-cc2127059a7624c4bd840e11d106cb81

This whole parseModifiers method is very confusing...

I flipped these two lines so I can access node.localSymbol in declareSymbol so can check if two default exports do not have the same identifier. Maybe this is better handled in checker.ts?

I added this project test to test the .d.ts output, is there a better way? Can I suppress the .js output?

We are trying to avoid adding new "projects" tests in favor test variations in compiler/conformance tests. You can set // @declaration: true in the compiler/conformance tests to get .d.ts output.

MergeDeclarationMarker are unnecessary if the variable is initialized immediately. I think the logic handling those in the other locations is now dead.

Are there any other places that still create a MergeDeclarationMarker? If not are we able remove it completely from types.ts/factory.ts?

It shouldn't be necessary to set the comment range if you've also set the text range. Setting the text range sets the pos and end of enumStatement to be that of node, which affects both comment emit and source map emit. Setting the comment range should be redundant.

Do we no longer need the end-of-declaration marker node? It's used to handled deferred exports for ES2015, CommonJS, AMD, and SystemJS. If we no longer need it I would remove this line rather than just comment it.

Is it possible to make this change to emit behavior conditional on when it is necessary rather than always emit this way? It would significantly reduce the number of test changes in the PR.

Are there any other places that still create a MergeDeclarationMarker? If not are we able remove it completely from types.ts/factory.ts?

The indentation here is wrong.

B is never exported, despite the fact it is declared as export enum B in the test.

Our compiler runner supports test variations for the same source. Instead of multiple nnnTargetXModuleY.ts files you can do this instead:

That would be nice, but it doesn't look like it's in yet?

Error: Unknown value 'es5, es2015' for compiler option 'target'.

Our compiler runner supports test variations for the same source. Instead of multiple nnnTargetXModuleY.ts files you can do this instead: