Replacing object reference before exporting causing problems

[tjoskar]

Hi,

If I have the following typescript code:

var obj = {
    someKey: 6
};

// For some reason I want to change the object
obj = {
    someKey: 7
};

export {obj};

it compiles to:

var obj = {
    someKey: 6
};
exports.obj = obj;
obj = {
    someKey: 7
};

So if I importing the object I get:

import {obj} from './some-file';
console.log(obj.someKey === 6); // true

But I was expecting 7. I.e. I was expecting the following JS code:

var obj = {
    someKey: 6
};
obj = {
    someKey: 7
};
exports.obj = obj;

Is this a bug or expected behavior?

I am using version 1.6.0-dev.20150731 but it has the same behavior in 1.5.3.

[tjoskar]

A maybe more realistic example:

import {configInterface} from './config-interface';
import {defaultConfig} from './default';
import {localConfig} from './local';
import {productionConfig} from './production';
import {defaultsDeep} from 'lodash';

var config: configInterface;

if (process.env.NODE_ENV === 'production') {
    config = defaultsDeep<Object, configInterface>(productionConfig, defaultConfig);
} else {
    config = defaultsDeep<Object, configInterface>(localConfig, defaultConfig);
}

export {config};

If I import config after compiling, it will be undefined.
If I try to create the variable inside the if statement (which I don't want) I get the following code:

typescript:

if (true) {
    var k = {};
} else {
    var k = {};
}
export {k};

compiles to:

if (true) {
    var k = {};
}
else {
    var k = {};
}

[mhegazy]

The current behavior is by design. we assume that the variable initialization happens at declaration site. We have talked about this before, and there is not a foolproof way of doing it. but i think a better approch is to emit the export declaration where it was in the input code relative to other statements, this way you at least have control over how it works.

[ahejlsberg]

As I mentioned in the comments on #4259, emitting the export assignment at the location of the export declaration will break the following code:

export { foo };
var foo = 1;

Export declarations will quite often appear before the entity they're exporting.

I don't know that there is a solution that doesn't have some problem, and I still think our current scheme is the best compromise. Another alternative is to put the assignment at the very end of the module, but emitting it at the place of the export declaration isn't a viable solution in my opinion.

[ahejlsberg]

Just so we have all the data in one place, here are the possible solutions and their issues:

• Emit export assignment at variable declaration site as we do now. Only works when declaration has an initializer.
• Emit export assignment at export declaration site. Doesn't work when export declaration precedes variable declaration and/or assignments.
• Emit export assignment at end of module. Doesn't work when module initialization code makes calls to functions in other modules and those functions access the exported variable (true for the first two above as well when function calls precede export assignment).
• Rewrite variable references to export property references. Doesn't work when variable is exported by multiple names.
• Rewrite to properties with get and set accessors. Gets us closer to ES6 semantics, but much larger change, doesn't perform as well, and doesn't work at all for ES3.

Probably the best alternative to our current scheme is to emit all the export assignments at the end of the module. But, really, we're just trading one set of issues for another.

[mhegazy]

@ahejlsberg if we can not, or would not, emulate the ES6 semantics correctly by rewriting references, emitting the export declaration in the place it is authored is easier for users to understand.

I would argue that the case reported in this issue is more common than an export declaration before the variable is assigned. also see related report in #4162.

Moreover, with allowing the export declaration to be emitted at the user specified location, the user has a chance to workaround it, by moving the export declaration to the end of the file, where as the current scheme, there is no way to solve it unless you declare a new variable, and export that instead, which is not intuitive.

[ahejlsberg]

Yes, emitting the export assignment at the location of the export declaration allows the user to work around the problem. But it doesn't really solve the problem. If we're going to change this, wouldn't we solve more problems by emitting the export assignments at the end of the module? Surely this would make even more real world code work correctly. I think there are far more cases of export declarations preceding the variable declaration (which would become broken) than there are cases of the module initialization code making calls to functions in other modules that access exported variables of the calling module.

[cspotcode]

• Rewrite variable references to export property references. Doesn't work when variable is exported by multiple names.

Can you rewrite all variable assignments to also assign to the export? No need for getters. The local variable and all exports are kept in sync every time the exported variable is assigned.

export {foo as one, foo as two}
var foo = "hello";
foo = "world";

...generates:

var foo = exports.one = exports.two = "hello";
foo = exports.one = exports.two = "world";

Sorry to bump an old issue.

[mhegazy]

This should be working as intended in latest.