Skip to content
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

Feature Request: Ability to opt out of liveBinding with exports of const values #50214

Open
kwasimensah opened this issue Aug 8, 2022 · 1 comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript

Comments

@kwasimensah
Copy link

Suggestion

πŸ” Search Terms

liveBinding Object defineProperty allocation export live view

βœ… Viability Checklist

My suggestion meets these guidelines:

  • [ x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • [ x] This wouldn't change the runtime behavior of existing JavaScript code
  • [ x] This could be implemented without emitting different JS based on the types of the expressions
  • [ x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
  • [x ] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

opt out of liveBinding added in #35967 for const values

πŸ“ƒ Motivating Example

Doing some profiling of an app I'm creating and seeing a lot of calls to the get function of Object defineProperty that was added as part of #35967. These might be optimized away when not using --trace-allocation-stack-interval but it would be great to not have to rely on the optimizer to do the right thing here.

I originally wanted to add a flag that would make sure that

createExportExpression(factory.getExportName(specifier), exportedValue, /* location */ undefined, /* liveBinding */ true)
doesn't unconditionally pass true here, but that would be a breaking change to existing Typescript code if the flag was used with a modifiable export (does the breaking change guideline count if someone needs to explicitly flag themselves into a behavior?)

If the exported value is const then you don't need a "live view" of it. But it's not clear if there is a good way to communicate const-ness at the time the export expression is created.

πŸ’» Use Cases

I think I can work around this by saving the value of the re-export to a variable local to the the current script/module and using that. But that seems cumbersome.

@kwasimensah
Copy link
Author

Looking into this some more, I think I actually want to edit

statements = appendExportsOfDeclaration(statements, importBinding, /* liveBinding */ true);

A really simple example of the issue is

import {createHash} from "crypto";

export {createHash}
Output
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.createHash = void 0;
const crypto_1 = require("crypto");
Object.defineProperty(exports, "createHash", { enumerable: true, get: function () { return crypto_1.createHash; } });
Compiler Options
{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "alwaysStrict": true,
    "esModuleInterop": true,
    "declaration": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "target": "ES2017",
    "jsx": "react",
    "module": "ESNext",
    "moduleResolution": "node"
  }
}

Playground Link: Provided

@RyanCavanaugh RyanCavanaugh added Suggestion An idea for TypeScript Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature labels Aug 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

2 participants