GeezerVison

Hi James Whitney (@whitneyit), I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by Microsoft and real humans are currently evaluating your PR.

TTYL, MSBOT;

tagging Ron Buckton (@rbuckton), he is working on a proposal for this.

I would not call it extends, we now have more helpers than extends, and possibly more, and would not want to add a --noEmit flag. so i would say call it --noHelpers, --noHelperEmit, or helpers: none vs helpers:embed*,

I am bad with naming things in general, so suggestions appreciated.

I had a thought about that and the issue I ran into was what to do about __decorate, __metadata, and __param?

I was going to add an Array<string> type to src/compiler/commandLineParser.ts so that individuals could chose to opt out of that TypeScript generated code, but that seemed a little premature.

To clarify, the Array<string> could be used as you said for a flag like --noHelpers extends,param,decorate or something like that

I would argue that the group of users who want to control one heler would likely want to control all or at least would not mind if they are asked to. Hence my proposal of a single switch.

I agree. If you think it is within scope of the issue at hand I'll update the PR to --noEmitHelpers and make that work across the board

I would want to get Ron Buckton (@rbuckton)'s input on this as well.

I've renamed the variable, I'll await Ron Buckton (@rbuckton)'s input

If we don't emit the helper, then what happens when __extends is called? If it's that an existing __extends will be invoked, then perhaps we need to change our declaration of __extends to be more like:

var __extends = __extends || ...

So that we'll defer to your __extends if you provide it.

No existing helper will be called. It will be up to the developer to implement their own version. The use case for this is pretty much isolated to amd/umd modules due to the way the helper gets emitted over numerous files

A comment was made on a line diff that is now outdated. It shows how a developer would define their own __extends function specifically for this use case. This also will have the benefit of then being able to potentially score a 100% on code coverage

define('__extends', function () {
  return function (d, b) {
    for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p];
    function __() { this.constructor = d; }
     __.prototype = b.prototype;
    d.prototype = new __();
  };
});

Mohamed Hegazy (@mhegazy), in regards to your comment on #2911, would you want to implement the --noEmitHelpers flag as an Array<string> in src/compiler/commandLineParser.ts?

I was under the impression from your earlier comments that this would not be the case

wrap this whole section with if (!compilerOptions.noEmitHelpers) check.

Unless we want to have the user specify which helper they do/don't want.

thanks James Whitney (@whitneyit). In addition to my comment about removing the "__extends" from the AMD module header, we will need a test for the new flag. to add the test, you need to:

• add a new test file in test\cases\compiler.ts with a comment at the top of // @noEmitHelpers: true
• add handeling for the new switch in harnes.ts
  and in fileMetadataNames
• jake runtests
• jake baseline-accept

Mohamed Hegazy (@mhegazy) your above comment makes a lot of sense. I'll start making the appropriate tests and update the PR

I've taken my first pass at adding a test.Once we can determine a reasonable implementation for all the use cases amd, commonjs, umd, <script> I will add additional tests to cover.

I believe that there is still some discussion on whether Ron Buckton (@rbuckton)'s comment about tslib should be factored into this PR.

thanks James Whitney (@whitneyit), i have manually merged the change. We need a different change to manage adding a way to include polifills as well as helpers. we also need another repo for tslib, to get the basic __extends and __decorat..etc.

Ron Buckton (@rbuckton) please update this with your issue for including pollifills.

Thanks for the merge! I'll look out for the upcoming PR and help where I can 😄

It doesn't look like it was referenced here but #1622 seems relevant