Can __export emitter be controlled by emitEmitHelpers compile option?

[meenie]

I'm trying to achieve 100% code coverage and the function:

function __export(m) {
    for (var p in m) if (!exports.hasOwnProperty(p)) exports[p] = m[p];
}

is added in every file that does something like export * from './blah'.

Can that code be controlled by the compilerOptions.emitEmitHelpers flag? Then it can be added to https://github.com/ngParty/ts-helpers and code coverage can go to 100% :).

I'm using https://github.com/hapijs/lab and it reports this:

[meenie]

This in the "too hard" bucket? :)

[kitsonk]

Can that code be controlled by the compilerOptions.emitEmitHelpers flag?

Yes.

Option	Type	Default	Description
--noEmitHelpers	boolean	false	Do not generate custom helper functions like __extends in compiled output.

[meenie]

@kitsonk Right... All the other helpers are controlled by that option, except for __export().

[RyanCavanaugh]

@rbuckton what's the intended behavior of the flag vs __export ?

[mhegazy]

We could elevate it to be a real, i.e. check if there is an override, do not emit it with --noEmitHelpers and import it from a helper library with --importHelpers (TS 2.1 feature).

one thing to note this will be a breaking change for users with --noEmitHelpers today, but i would say it an't too bad.

A PR would be appreciated. you will need to change the helper itself to not be based on closure, emit it at the top along with other helpers, and make sure it is only emitted when needed, and add a check to the make sure that external helper libraries implement it (using verifyHelperSymbol).

[rbuckton]

The __export helper closes over the exports value, and is unique to every module, which is why it does not respect this switch.

We could consider adding an __export helper using the following definition instead:

var __export = (this && this.__export) || function (exports, m) {
  for (var p in m) if (!exports.hasOwnProperty(p)) exports[p] = m[p];
}

And change all call sites to pass in the exports declaration. However, this would be a breaking change for anyone who currently uses --noEmitHelpers that currently depends on __export.

@meenie Another option is to add a custom lab transform for the __export function, per the documentation:

• -T , --transform - javascript file that exports an array of objects ie. [ { ext: ".js", transform: (content, filename) => { ... } } ]. Note that if you use this option with -c (--coverage), then you must generate sourcemaps and pass sourcemaps option to get proper line numbers.

[meenie]

Another option is to add a custom lab transform for the __export function, per the documentation:

@rbuckton That's what I ended up doing :). This should still be addressed, though. I assume it's affecting other people.

[gilboa23]

@rbuckton Yes, but I was not referring to the existing --noEmitHelpers flag. What I meant was to apply this change just over the new --importHelpers flag by passing the local exports symbol in the invocations of the imported tslib.__export() function. This should not be a breaking change since this is a now starting to be used. Something like:

// @module: amd
// @importHelpers: true
export * from "A";
export * from "B";

Output:

define(["require", "exports", "tslib", "A", "B"], function (require, exports, tslib_1, A_1, B_1) {
    "use strict";
    tslib_1.__export(A_1, exports);
    tslib_1.__export(B_1, exports);
});

See also related comments in PR 9097