-
Notifications
You must be signed in to change notification settings - Fork 12.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Array destructuring is transpiled with __read
helper even when asking for no transpilation and no inline helper functions.
#43541
Comments
__read
helper even when asking for no transpilation and no inline helper functions.
The @rbuckton, is this intentional, or is |
I'm happy to change my flags if I can both avoid the helpers and get correct behavior. Unfortunately, when I turn off "use strict";
var _a;
Object.defineProperty(exports, "__esModule", { value: true });
exports.V = exports.A = void 0;
_a = foo(), exports.A = _a[0], exports.V = _a[1]; |
We use the We could also investigate updating the "use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.V = exports.A = void 0;
[exports.A, exports.V] = foo(); I think we do the general downleveling for the sake of emit simplicity, rather than |
Here's an interesting variation: declare function foo(): any;
const [A, V] = foo();
export { A, V } Changing the export syntax prevents the downleveling. |
@rbuckton, I agree that in the long term, we should eventually switch from For the time being, is there any guidance on which code patterns will need to depend on the |
I have the same problem with a for-of loop, but I think I found the trick: script1.ts: const array = [1, 2, 3];
for (const value of array) {
console.log(value)
} will be transpiled to var __values = (this && this.__values) || function(o) {
var s = typeof Symbol === "function" && Symbol.iterator, m = s && o[s], i = 0;
if (m) return m.call(o);
if (o && typeof o.length === "number") return {
next: function () {
if (o && i >= o.length) o = void 0;
return { value: o && o[i++], done: !o };
}
};
throw new TypeError(s ? "Object is not iterable." : "Symbol.iterator is not defined.");
};
var e_1, _a;
var array = [1, 2, 3];
try {
for (var array_1 = __values(array), array_1_1 = array_1.next(); !array_1_1.done; array_1_1 = array_1.next()) {
var value = array_1_1.value;
console.log(value);
}
}
catch (e_1_1) { e_1 = { error: e_1_1 }; }
finally {
try {
if (array_1_1 && !array_1_1.done && (_a = array_1.return)) _a.call(array_1);
}
finally { if (e_1) throw e_1.error; }
}
//# sourceMappingURL=test2.js.map script2.ts: export function fuu() {
const array = [1, 2, 3];
for (const value of array) {
console.log(value)
}
}
fuu(); will be correctly transpiled to Object.defineProperty(exports, "__esModule", { value: true });
exports.fuu = void 0;
var tslib_1 = require("tslib");
function fuu() {
var e_1, _a;
var array = [1, 2, 3];
try {
for (var array_1 = tslib_1.__values(array), array_1_1 = array_1.next(); !array_1_1.done; array_1_1 = array_1.next()) {
var value = array_1_1.value;
console.log(value);
}
}
catch (e_1_1) { e_1 = { error: e_1_1 }; }
finally {
try {
if (array_1_1 && !array_1_1.done && (_a = array_1.return)) _a.call(array_1);
}
finally { if (e_1) throw e_1.error; }
}
}
exports.fuu = fuu;
fuu();
//# sourceMappingURL=test1.js.map so the difference is that in the second script, which imports tslib (this is what is expected), the code is wrapped by a function. In the first script the code is in the global scope and then typescript emits the helper functions as expected. |
If you remove |
Hi there. I started looking into this. Here is my current understanding of why this happens. This is roughly the order of transformations in the compilation process:
This means that I see 2 ways to fix this:
Is my understanding correct? And which option would you prefer? I can try to work on a PR. But would like to make sure I go in the right direction π |
From a user's perspective, I think it would be nicer if the module transformation didn't depend on helpers that are not used in the But I think folks on the MS side might have a preference on which approach would fit better with the TSC architecture. |
Specifying Any change here would require branching on the target ECMAScript edition to control how much of the destructuring transform we actually need. |
Aside from this, there's no other reason to use |
Bug Report
π Search Terms
array destructuring
downLevelIteration
importHelpers
ESNEXT
CommonJS
π Version & Regression Information
importHelpers
β― Playground Link
Playground link with relevant code
Note: I'm not sure how to reliably get the
target
option to encode into the URL; you may need to set the target manually toESNext
(or any other value >=ES2015
)π» Code
π Actual behavior
The
__read
transpilation helper was injected into the output JS, even though I specified that I didn't want transpilation (throughtarget=ESNEXT
). Additionally, the transpilation helper was injected inline even though I specified theimportHelpers=true
option.π Expected behavior
I was expecting output that leveraged the
target=ESNEXT
setting to include the array destructuring in the output code, like:The text was updated successfully, but these errors were encountered: